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.