Can someone please explain the set-user-ID mechanism in Unix ? What was the rationale behind this design decision? How is it different from effective user id mechanism ?
You might know the normal read, write and execute permissions for files in unix.
However, in many applications, this type of permission structure--e.g. giving a given user either full permission to read a given file, or no permission at all to read the file--is too coarse. For this reason, Unix includes another permission bit, the
To set the set-user-ID bit for a file, type
Make sure that you have set group-other execute permission too; it would be nice to have group-other read permission as well. All of this can be done with the single statement
It is also referred to as Saved UID. A file that is launched that has a Set-UID bit on, the saved UID will be the UID of the owner of the file. Otherwise, saved UID will be the Real UID.
What is effective uid ?
This UID is used to evaluate privileges of the process to perform a particular action. EUID can be changed either to Real UID, or Superuser UID if EUID!=0. If EUID=0, it can be changed to anything.
An example of such program is
Rather than calling "set UID" and "effective UID" a mechanism, the whole concept of UIDs should be called that. The rationale for existence of the various UIDs are various troubles with privilege separation. Even regular (unprivileged) users sometimes need to do things (access resources) that only privileged users can. To achieve this easily, programs can change their UIDs. There are 3 types of these:
The need for the last one arises from the fact, that regular users can only switch between these three and nothing else and a setuid program usually needs to know somehow, who was the user who loaded it (plus the real UID should not be changed since that would create even bigger mess).
mtk's expalanation is a good one.
Another rationale is to protect the user in the same manner as you might use
Note that it is possible to set uid programmatically even if the suid bit is not set on the executable, however, that will not work for escalation. Ie., if you are a normal user and write a program that sets uid at some point itself, that program cannot switch to root. Apache works this way, I believe. It is usually started by root and has one process that then forks children which switch uid to a non-privelleged user (eg, "httpd"). Those child processes are what do the actual web server work.