APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed



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.

Got something to add? Send me email.

Increase ad revenue 50-250% with Ezoic

More Articles by

Find me on Google+

© Tony Lawrence

---September 21, 2004 Your example should use a different name for the gid. It is confusing to the novice as to what's going on when the gid and uid are the same.
Also chmod 2755 prog would result in rwxr-sr-x and not rwsr-xr-x.

---September 21, 2004

Correct. Will fix :-)


Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

FORTRAN—the "infantile disorder"—, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use. (Edsger W. Dijkstra)

The idea of "work, then get paid" has been deeply ingrained in our culture by employers who want to limit their risk. Well, I like to limit my risks also. I like to get paid before I do work. (Tony Lawrence)

This post tagged: