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:
The saved user id allows the program to shed its more powerful identity when it doesn't need it.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2011-07-05 Tony Lawrence