| SUPER(1) | General Commands Manual | SUPER(1) |
super - execute commands setuid root.
To execute a command:
super [ -r reqpath] command [ args ]
super [ -r reqpath] -o path [
args ]
command [ args ]
To list available commands:
super [-H|-f] [-S]
For usage and/or version information:
super [-h] [-V]
For debugging and development:
super -b
super -c [ superfile ]
super [-d|-D|-t] [-S] [MasqOptions]
[-H|-f|command...]
MasqOptions:
-F file -T hh:mm/dayname -G gid -U uid -M mach
Super allows specified users to execute scripts (or other commands) as if they were root; or it can set the uid, gid, and/or supplementary groups on a per-command basis before executing the command. It is intended to be a secure alternative to making scripts setuid root. Super also allows ordinary users to supply commands for execution by others; these execute with the uid, gid, and groups of the user offering the command.
Super consults a ``super.tab'' file to see if the user is allowed to execute the requested command. If permission is granted, super will exec pgm [ args ], where pgm is the program that is associated with this command. (Root is allowed execution by default, but can still be denied if a rule excludes root. Ordinary users are disallowed execution by default.)
The most common sort of entry in a super.tab file pairs a
simple command with a pgm path. But in fact, the command in
the super.tab file is actually treated as a pattern, and any
user-entered command that matches this pattern causes the associated
pgm to be executed. If the listed pgm contains an asterisk,
then the asterisk is replaced with the command entered by the user. One use
of this is to let any program in a certain directory be executed by a user.
For example, if the entry contains the command/pgm pairs
CommandPattern Program
scripts/* → /usr/local/super/*
* → /usr/local/somedir/*
then the translations made are User's Command Executed Program
scripts/xyz → /usr/local/super/scripts/xyz
xyz → /usr/local/somedir/xyz
Some commands can only be run after the user enters his or her password. These commands can then be run multiple times until some expiration time, at which point the password needs to be re-entered. The list of password-requiring commands and the password durations are set in the same file that records the valid users for each command.
If command is a symbolic link (or hard link, too) to the
super program, then typing % command args
is equivalent to typing % super command args
(The command must not be super, or super will not
recognize that it's being invoked via a link.)
Super without any arguments will display the list of commands that may be executed by the user.
For security, the following precautions are taken before exec'ing:
USER and LOGNAME: both are set to the username associated with the real uid of the program running under super;
HOME: set to the login directory of the user running super;
ORIG_USER, ORIG_LOGNAME, ORIG_HOME: the values of USER, LOGNAME, and HOME that refer to the user who invoked super. (These values are computed by super, and are not the values set by the caller, so they are a reliable description of the caller. These are normally the same values as USER, LOGNAME, and HOME, but they will differ if the super command changes uid or gid before executing the program.);
IFS: set to blank, tab, newline;
PATH: set to /bin:/usr/bin.
SUPERCMD: set to command.
additional environment variables as specified in the super.tab file (see below).
If Super is executed without arguments, it will print the
commands that the user may execute, one command per line. Super -H
prints a long-winded description of each command that the user may execute.
The CmdPat is the command pattern, and FullPath is the full path
that will be executed. The super.tab file can specify initial arguments that
that precede any user-supplied arguments; these arguments, if any, are
printed after the FullPath column.
Ordinary users can supply their own super files. This lets users give well-controlled setuid/setgid access to their programs: the user who offers the program gets the assurance of safe IFS settings, safe environment variable settings, etc; and the user who executes the program knows that it will execute under the uid and gid of the offering user. If a command is entered in the form
The usual super options (such as -H) can be applied to a
user's .supertab file. For example, help information about one command can
be had by using: super -H loginname:cmd
Likewise, help information about all of loginname's commands can be
obtained with: super -H loginname:
Links to per-user commands can be created and used in a manner similar to making symlinks to super itself. If command is a symbolic link to a user's .supertab file, and that .supertab file is
(a) executable, and
(b) begins with
then the following pair are completely equivalent:
#! /bin/sh
# Keep this backslash -> \
exec /long/path/to/the/super/executable -o $0 ${1+"$@"}
Per-user .supertab linking works as follows: if /path/to/xyz is a symlink to some user's .supertab file, and the .supertab file begins with #! /path/to/super -o, then the shell will invoke super with arguments something like
** Security Warning **
Note that if you use symlinks to a per-user .supertab file, then you must
trust that the .supertab file will actually execute a super command, instead
of doing something nasty. That is because super itself isn't invoked
until the shell has opened the .supertab file and done whatever the
.supertab file tells it to do. By contrast, the direct command
super loginname:cmd doesn't involve any
shell processing of the .supertab file.
Example 1. super skill → /usr/local/bin/skill
Typing super skill will execute /usr/local/bin/skill.
Example 2. super {lp*} → /usr/bin/*
This example contains asterisks on both the left and right sides. The left side shows the valid pattern you must match to execute the command shown on the right-hand side. Usually, the right-hand side has no asterisk, just a full path to a command to execute. If there is an asterisk present, it is replaced by the command you entered, thereby forming the actual executed command. Thus, if you type super lpxxx (where xxx is any string), super will execute /usr/bin/lpxxx.
Example 3. super {co*} → /usr/bin/compress
The asterisk on the left-hand side means you can enter super coxxx (where xxx is any string), but since the right-hand side doesn't contain an asterisk, coxxx will always execute /usr/bin/compress.
prog=`basename $0` /usr/local/bin/super -t -r $0 $prog case $? in 0 ) exec /usr/local/bin/super -t -r $0 $prog ;; * ) echo "Super $prog doesn't work!"
... So take appropriate action ...
;; esac
These options are useful when creating and debugging super.tab files. They have little or no value to the everyday user. With the exception of the -b option, they can be combined with the regular options, above.
Note that super -c isn't a complete check that you've correctly set up an entry, because you can create syntactically valid entries that don't do exactly what you want. Therefore, you should also use super -d cmd to make sure that the command you've entered will be executed with the correct arguments, uid, gid, umask, and so on.
You must be exceedingly careful when writing scripts for super. A surprising variety of ordinary commands can, when run setuid-root, be exploited for nasty purposes. Always make your scripts do as little as possible, and give the user as few options as possible.
Think twice about side-effects and alternative uses of these scripts. For instance, make sure your script doesn't quietly invoke the user's .cshrc or similar file. Or, you might write a script to allow users to mount cd-rom's by executing mount(8). But if you don't write it carefully, a user could mount a floppy disk containing, say, a setuid-root shell.
Security issues aside, here are some hints on creating super scripts:
#!/bin/sh
prog=`basename $0`
test "X$SUPERCMD" = "X$prog" ||
exec /usr/local/bin/super -r $0 $prog ${1+"$@"}
Will Deich
will@ucolick.org
If the super.tab file isn't owned by root, or if it is group- or world-writable, super won't run setuid-root. (If the user's real uid is root, super won't run at all; otherwise, the effective uid reverts to real uid.)
There is a race condition when using password-requiring commands, but it doesn't affect security: if a user is running two copies of super simultaneously, and both processes try to update the user's password timestamp file at the same time, then it is possible for one of the super commands to fail. Workaround: a single user shouldn't execute two password-requiring super programs simultaneously.
| local |