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:
setuidprograms with privileged user IDs such as
rootunless 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.
execfunctions 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
execvpfunctions are a potential risk (since the program they execute depends on the user's
PATHenvironment variable). If you must
execanother 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.
setuidpart 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
accessfunction (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.