Real UID, effective UID, and some systems even have a "saved UID". What's the purpose of all these, especially the last one?
+7
A:
Each UNIX proces has 3 UIDs associated to it. Superuser privilege is UID=0.
Real UID
This is the UID of the user/process that created THIS process. It can be changed only if the running process has EUID=0.
Effective UID
This UID is used to evaluate privileges of the process to perform a particular action. EUID can be change either to RUID, or SUID if EUID!=0. If EUID=0, it can be changed to anything.
Saved UID
If you run an exectuable with the set-UID bit set, then the resulting running process will start off with a real UID of the real user running it, and an effective 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 original privileges again thanks to the saved UID. If the set-UID bit is not set, SUID will be the RUID.
Barth
2008-10-15 15:22:50
What's the purpose of Saved UID?
raldi
2008-10-15 15:26:35
It's for security and audit purposes, i.e. to be able to determine which user account actually launched the binary? If it weren't around, all you would be able to get is the file owner's UID since running with the file owner privileges is what the SUID bit is for.
Mihai Limbășan
2008-10-15 17:01:26
The saved UID is so a process can switch its effective UID to its real UID, then back again; otherwise it would be a one-way operation.
MarkR
2008-10-15 20:33:50
I tried to clarify the purpose of the Saved UID with what you said MarkR.
Barth
2008-10-16 06:24:09
You mean "elevate", not "evaluate", right?
Jim Hunziker
2009-06-18 17:44:54
+2
A:
The real uid is the id of the user that launched a process.
The effective uid typically is the same as the real uid. It is different only if:
the executable had the set-uid bit set, and the executable owner is different than the user calling it
or if a set-uid process calls setuid(2). If the process has superuser privileges, any argument to setuid(2) is allowed (but then all *-uids get set to the same value); otherwise, setuid(2) can be called with the real-uid or the effective-uid or the saved-uid.
The saved-uid is the effective-uid the process had when it started, and it's saved in order to be allowed as an argument to the various set*uid system calls.
Note that a process with superuser privilege calling setuid(2) to change its effective uid will also have the real uid and saved uid changed to the same value, so the non-POSIX seteuid(2) should be used instead.
All of the above apply to (real|effective|saved) group ids too.
ΤΖΩΤΖΙΟΥ
2008-10-15 15:30:00
Second bullet isn't correct - calling setuid() will not, of itself, make the EUID different from the RUID unless the process previously had RUID != EUID (so it might reinstate the state at program start). The rest of the bullet is more or less accurate.
Jonathan Leffler
2008-10-19 02:45:14
Thanks for the suggestion; I believe I corrected the second bullet by adding one word.
ΤΖΩΤΖΙΟΥ
2008-10-19 21:55:19
A:
In addition to the real, effective, and saved UIDs, Unix systems with auditing enabled also have the audit UID. A process's AUID identifies the user who started the process; it is not changed by setuid(2) or seteuid(2). The intent is that it remains constant through the process and is used only to tag audit records. Thus, if a user executes a privileged shell (even an authorized user via su or sudo), the audit records of that process are tagged from that user.
mpez0
2008-10-19 22:38:15