Next: Who Logged In, Previous: Setuid Program Example, Up: Users and Groups [Contents][Index]
It is easy for setuid programs to give the user access that isn’t intended—in fact, if you want to avoid this, you need to be careful. Here are some guidelines for preventing unintended access and minimizing its consequences when it does occur:
setuid programs with privileged user IDs such as
root unless it is absolutely necessary. If the resource is
specific to your particular program, it’s better to define a new,
nonprivileged user ID or group ID just to manage that resource.
It’s better if you can write your program to use a special group than a
special user.
exec functions in combination with
changing the effective user ID. Don’t let users of your program execute
arbitrary programs under a changed user ID. Executing a shell is
especially bad news. Less obviously, the execlp and execvp
functions are a potential risk (since the program they execute depends
on the user’s PATH environment variable).
If you must exec another program under a changed ID, specify an
absolute file name (see File Name Resolution) for the executable,
and make sure that the protections on that executable and all
containing directories are such that ordinary users cannot replace it
with some other program.
You should also check the arguments passed to the program to make sure they do not have unexpected effects. Likewise, you should examine the environment variables. Decide which arguments and variables are safe, and reject all others.
You should never use system in a privileged program, because it
invokes a shell.
setuid part of your program needs to access other files
besides the controlled resource, it should verify that the real user
would ordinarily have permission to access those files. You can use the
access function (see Access Permission) to check this; it
uses the real user and group IDs, rather than the effective IDs.
Next: Who Logged In, Previous: Setuid Program Example, Up: Users and Groups [Contents][Index]