sudoshell, ss - Run a shell with logging
sudoshell|ss [-] [-u|--user username]
This manpage documents version 2.1.2 of sudoshell.
sudoshell runs the script command with a fifo as the typescript. Used in conjunction with sudoscriptd(8) and sudo(8), it provides a way to maintain the sudo audit trail while running a shell.
sudo is a tool used for running programs with privileges other than those normally possessed by the user. Often, the privileges are those of the root account, but they could as well be those of any other user. One of sudo's major benefits is the audit trail it provides, as it logs each invocation with the command name, its arguments and the user who ran it. Because this audit trail is lost if a user runs a shell (e.g. bash or csh) with sudo, many sites restrict sudo to not allow such usage. Since this can cause problems, (see SUDO AND SHELLS) many users prefer to retain the root password, even if it means forgoing support. This outcome also results in a loss of the audit trail, while increasing the chances that an unmanaged system will become a support problem later.
Sudoshell is a small Perl script that works in conjunction with a logging daemon (see sudoscriptd(8)) to log all activity within a shell. It uses the unix script(1) command to create the log. Once invoked, all console commands and output are logged to a fifo. The logging daemon reads from this fifo and manages log files to store the data produced. The logs are rotated to ensure that they do not overflow the disk space on the logging partition.
When started, sudoshell checks to see if sudoscriptd(8) is running and offers to start it if it is not. (It does this with sudo, so you need to have sudo root access to perform this step. See CONFIGURATION below) Sudoshell then checks to see if it has been run as the correct user (either root or some other user with the -u switch. See below.) via 'sudo sudoshell' or otherwise. If not, it reinvokes itself using sudo. The script then checks the user's shell. If the SHELL environment variable is set, sudoshell uses that. If not, the shell entry from the passwd file is used. If the value thus obtained doesn't match one of the shells listed in /etc/shells, sudoshell refuses to run. Finally, sudoshell execs script(1), pointing the output to a logging FIFO maintained by sudoscriptd(8), which gives the user a shell as the desired user.
sudoshell uses sudo(8) to perform all its authentication and privilege escalation. The sudoshell user must therefore be in the sudoers file (See sudoers(5).) with an entry that allows running sudoshell as the desired user. See the SUDOCONFIG file in the distribution for details. (On Linux, this will be in /usr/share/doc/sudoscript-VERSION. Everywhere else, it's in /usr/local/doc/sudoscript-VERSION.)
Example:
sudoshell -u oracle
The idea of running shells as users other than root came from Donny Jekels.
Most root tasks can be accomplished with sudo without running a shell. However certain tasks, such as running privileged commands in a pipeline, can be more difficult using sudo. Since sudo sometimes prompts for a password (depending on how long ago the user last authenticated) you can run into quirky situations like this:
hbo@egbok|509> sudo ls | sudo more Password:Password:(enter password) (enter password) #sudoshell# CVS sudoscriptd sudoscriptd~ sudoshell sudoshell~ hbo@egbok|510>
In this case we get two password prompts, right on top of one another. We enter the password for the first prompt, and sudo waits for the next one. Since the prompt is on the preceding line, this can be very confusing.
Another place sudo has difficulty is with I/O redirection:
hbo@egbok|511 > ls -l /tmp/foo -r--r--r-- 1 root other 1464 Mar 25 13:10 /tmp/foo hbo@egbok|512 > sudo ls >>/tmp/foo bash: /tmp/foo: Permission denied hbo@egbok|513 > sudo ls | sudo cat >>/tmp/foo bash: /tmp/foo: Permission denied
But this works:
hbo@egbok|514 > sudo ls | sudo tee -a /tmp/foo >/dev/null
It's not very intuitive, however.
The problem occurs because the shell implements I/O redirection before it invokes the command, which is sudo, NOT ls.
Globbing has problems for the same reason. But in this case, there's no good workaround, short of letting the user run a shell:
hbo@egbok|515 > mkdir fff hbo@egbok|516 > chmod 700 fff hbo@egbok|517 > touch fff/foo hbo@egbok|518 > sudo chown root fff Password: hbo@egbok|519 > cd fff bash: cd: fff: Permission denied hbo@egbok|520 > sudo cd fff sudo: cd: command not found hbo@egbok|521 > sudo rm fff/* rm: cannot remove `fff/*': No such file or directory
The cd fails because cd is a bash builtin, and sudo doesn't know anything about it. The ``globbing'' fails because the shell tries to expand the wildcard before executing the command, which is sudo, not rm.
Please let me know if you find any.
sudoscript(8)
sudoscriptd(8)
Sudoscript(3pm)
sudo(8)
sudoers(5)
sudo - http://www.courtesan.com/sudo/index.html
Solaris
Linux
OpenBSD
FreeBSD
HP-UX
UNIX/System_administration
The following people offered helpful advice and/or code:
Dan Rich (drich@emplNOoyeeSPAMs.org) Alex Griffiths (dag@unifiedNOcomputingSPAM.com) Bruce Gray (bruce.gray@aNOcSPAMm.org) Chan Wilson (cwilson@coNrOp.sSgPi.cAoMm> Tommy Smith (tsNmOith@eSaPtAeMl.net) Donny Jekels (donny@jNOeSkPeAlMs.com
Howard Owen, <hbo@egbok.com>
Copyright 2002,2003 by Howard Owen
sudoscript is free software; you can redistribute it and/or modify it under the same terms as Perl itself.