A.P. Lawrence

2004/01/29 setuid

You don't have to hang around Unix long to learn about "su" and setuid programs. The "setuid()" system call (and related calls like setgid) are what allows a process to switch back and forth between id's.

The kernel actually maintains three id's: the real user id, the effective user id, and the saved user-id. The saved user id is important and very useful in writing more secure programs.

Only a process that already has superuser power can change its real user id, and you often see setuid programs (the binary has had a chmod 4755 for example) owned by root so that the process has root capability when executed. But because of the saved user id, you don't necessarily have that effective id throughout: for security reasons, programs should switch you back to the saved id whenever having the more powerful id isn't necessary.

Take the example of a program that needs to open some database files, allow you to review and possibly change datam, and then write the files. Let's set the files for ownership by the "database" account:

# chown database:database datafile
# chmod 660 datafile
# chown database prog
# chmod 4755 prog
# ls -l prog datafile
-rw-rw----    1 root     database        0 Jan 19 08:13 datafile
-rwsr-xr-x    1 database tony        0 Jan 19 08:13 prog

When our "prog" is executed, its effective id will become "database", so it can read the file. When it is time to write the data back, it also needs the "database" effective id, but it doesn't need it in-between. So, ideally, the flow would go something like this:

• prog is executed. Real gid is you, effective id is "database". The saved user id is also "database". The program open the file and reads it into memory. It also saves the numerical database id.
• It now executes setuid(getuid()) to change the effective user id back to you. If you managed a shell escape at this point, you'd have no more power than you ever did: you couldn't read or write datafile.
• When it is time to write data, the program does a setuid(databaseid). The only reason that works is because of the saved user id: that was and is database, so the process is allowed to switch back to that. It can't switch to any other ids other than yours and that because it does not have superuser privileges.

The saved user id allows the program to shed its more powerful identity when it doesn't need it.