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.)

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 shell.

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:

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.

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.