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.
system and 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 section 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.
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 section How Your Access to a File is Decided) to check this; it
uses the real user and group IDs, rather than the effective IDs.
Go to the first, previous, next, last section, table of contents.