Unix Real-UID, Effective-UID and Saved-UID [转]

Real-UID:

• Real-UID is the id of the user that launched a process.

Effective-UID:

• Effective-UID is usually the same as the Real-UID. However, sometimes a user needs to access resources (like files) that they don’t have ownership of. If it requires such access, the Effective-UID changes from its Real-UID to the UID of the user who owns that resource.
• Effective-UID is used to evaluate privileges of the process to perform a particular action.
• If the Effective-UID != 0 (not root), Effective-UID can be changed either to Real-UID, or Saved-UID.
• If the Effective-UID = 0 (root), it can be changed to anything.
• Most of the time, the kernel checks only the Effective-UID. For example, if a process tries to open a file, the kernel checks the Effective-UID when deciding whether to let the process access the file. If the kernel cares about only the effective user ID, it doesn’t seem like there is much point in having a distinction between a Real-UID and an Effective-UID. However, there is one very important case in which the real user ID matters. If you want to change the Effective-UID of an already running process, the kernel looks at the Real-UID as well as the Effective-UID.

Saved UID:

• If you run an executable with the set-UID bit set, then the resulting running process will start with a Real-UID of the real user running it, and an Effective-UID and Saved-UID of the owner of the executable file. If the process then calls “setuid” or “seteuid” to change their Effective-UID, they can still get back their origin al privileges again thanks to the Saved-UID. If the set-UID bit is not set, Saved-UID will be the Real-UID.
• The Saved-UID is there so a process can switch its Effective-UID to its Real-UID, then back again; otherwise it would be a one-way operation.

What is the idea?

At the lowest level of the operating system (the kernel), users are not identified by names, but numbers called user IDs (UID). The user ID 0 is commonly called “root”.

Each Unix process has a UID associated with it, and when trying to open a file for writing, for instance, this ID is used to determine whether the process should be granted access or not.

When you invoke the “passwd” utility, the Effective-UID of the process is set to 0, i.e. the UID of the root user. As a result, the program is permitted to modify the /etc/passwd file, and can thus replace the encrypted password in your account entry with the new one you just provided.

As a normal user, you’re only allowed to modify the password of your own account using the “passwd” utility and it doesn’t let you modify the password of any other account. So now the question is, how does the program know who invoked the utility?

That is where another UID comes in, called the Real-UID, which is used to track who the user really is. This Real-UID value is not changed when you invoke programs such as “passwd”. So the program simply needs to find out what user name corresponds to its Real-UID, and refuse to change any other account.

Normal programs, like "ls", "cat" run by a normal user under that users Real-UID. Special programs that allow user to have controlled access to protected data, can have Set-UID bit to allow the program to be run under privileged UID.

Example:

When a normal user (say "mhasan") runs the program "passwd", it starts with:

Real-UID = mhasan
Effective-UID = mhasan
Saved-UID = root

The the program (passwd) then calls a system call "seteuid ‘and since Saved-UID = 0, the call will succeed and the UIDs will be:

Real-ID = mhasan
Effective-UID = root
Saved-UID = root

After that, "passwd" process will be able to access /etc/passwd and change password for user "mhasan".