There are two different, but related, concepts on Unix and Unix-like operating systems, both of which use the term setuid.

  • The setuid system call
  • The setuid bit in a file's mode
Both effect a change in the userid associated with a process. (And each has an analogue which deals with groupids.)

The setuid system call

This function changes the userid associated with the running process that calls it. It can only be used if the process is currently running as the superuser (i.e., has a userid of zero) [1]. When the function returns, the userid of the process has been changed to the requested value.[1] The most usual purpose of doing this is to drop superuser privileges and become a normal user. This, for example, is how you become you when you login. The login program is running with superuser privileges; after validating your username and password, it uses setuid(your userid) to become you, and then invokes your designated shell program which sets up your login session using your credentials.

Were it not for the setuid function, everybody would always have superuser privileges, since all processes are descendants of init, which is created during system boot as a superuser process.

The setuid mode bit

This mode bit (value 40008; 20008 in the case of the setgid bit) causes the userid of a process to change (to the owner of the executable file[2]) when the process execs an executable file with the bit set.[3] The purpose of this is to allow (usually system-supplied) programs that require a particular user's privilege to be run by other users (for example, you). For example, you don't have sufficient privilege to alter the system's password database; nonetheless, it would be ridiculous if you had to find someone with superuser access to change your password for you. Instead, the program that you use to change your password is installed with the setuid bit on, and is owned by root. Thus, when you run it, it has superuser privilege and is able to set your new password.

A previous writeup by Spasemunki talks only about the mode bit, but uses the term API, which would refer to the system function. E may also imply (one can't quite tell from his wording) that it is possible for a user to gain the privileges conferred upon a process that received them pursuant to a setuid mode setting if the program crashes, but this is not true.

[1] Technically not true, as each process has 2 different userids (called the real and effective userids. On some systems, there is even a third, called the saved userid.) The effective user id is what the system refers to when it decides to allow or not allow a process's request (to open a file, for example), and it is the effective userid that the setuid function changes. But all of that goes out the window if the calling process has superuser privilege -- in that case, both (or all three) of the ids are changed. This issue is very sensitive, and has been thought through by very smart people.

[2] All of these operating systems allow the setuid process to be applied to any native executable. Some also allow executable files which require an interpreter (which is how many programs are implemented these days) to use the setuid feature.

[3] Actually, only the effective id is changed.