sudoshell, ss - Run a shell with logging
sudoshell|ss [-] [-u|--user username
This manpage documents version 2.1.2 of 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.
is a tool used for running programs with privileges other than those
normally possessed by the user. Often, the privileges are those of the
account, but they could as well be those of any other user. One of
'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
(8)) to log all activity within a shell. It uses the
(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
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
(1), pointing the
output to a logging FIFO maintained by sudoscriptd
(8), which gives the
user a shell as the desired user.
(8) to perform all its authentication and
privilege escalation. The sudoshell
user must therefore be in the
file (See sudoers
(5).) with an entry that allows running
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
- Like 'su -'. This switch will load the environment of the user you become,
rather than retaining yours.
- -u <user>
- If this switch is given along with a username, sudoshell will ask
sudo to give the ss user the identity of the user named with the -u
switch. If no -u switch is given, sudoshell will ask for a root
sudoshell -u oracle
The idea of running shells as users other than root came from Donny
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
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
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.
sudo - <http://www.courtesan.com/sudo/index.html>
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, <firstname.lastname@example.org>
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.