"An improved arrangement for controlling access to data files by computer users. Access permission bits are used in the prior art to separately indicate permissions for the file owner and nonowners to read, write and execute the file contents. An additional access control bit is added to each executable file. When this bit is set to one, the identification of the current user is changed to that of the owner of the executable file. The program in the executable file then has access to all data files owned by the same owner. This change is temporary, the proper identification being restored when the program is terminated."
Interestingly, Ritchie's set-UID patent application was initially rejected, as the patent examiner considered the disclosure lacking in details. In the examiner's opinion, an ordinary programmer could not implement the mechanism by reading Ritchie's description. Ritchie took care of this issue by writing a small toy operating system with the UNIX file protection mechanism (without the set-UID portion), and gave it to a programmer in the local computer center, who implemented set-UID based on Ritchie's description, and signed an affidavit to that effect.
The fundamental problem solved by set-UID is that it allows a program running on behalf of one user operate as if it were running as another user. Consider an example. Suppose there is a sensitive file on a multi-user system that contains information about each user (
/etc/passwd, say), and it is desirable to allow each user to edit his own information in the file (the password, or the so-called GECOS field, say). The typical Unix solution is to have the password setting utility (
passwd) be set-UID root. The
passwd program is runnable by anybody, but it runs as root, and therefore is able to edit the password file. Since the program exposes very specific and limited legitimate functionality, things are fine as long as it is not possible to make the program do something unintended.
Early examples of set-UID use included a game-playing program that maintained records of players' scores (and thus required write-access to the scores file on behalf of a player).
The set-UID (and set-GID) mechanism went on to become an integral part of Unix, but also has been a primary vehicle for attacks against security, largely due to its all-or-nothing nature.
Today, a Unix process might have a number of user-id's (uid's), and correspondingly, a number of group-id's (gid's):
- real uid (the process owner's uid)
- effective uid (most access control decisions are based on this uid, which is usually the same as real uid, but may change)
- saved uid (the "previous" uid in a uid-change)
- filesystem uid (Linux uses this uid for filesystem access control decisions; usually the same as effective uid)