Difference between Real User ID, Effective User ID and Saved User ID
Solution 1
The distinction between a real and an effective user id is made because you may have the need to temporarily take another user's identity (most of the time, that would be root
, but it could be any user). If you only had one user id, then there would be no way of changing back to your original user id afterwards (other than taking your word for granted, and in case you are root
, using root
's privileges to change to any user).
So, the real user id is who you really are (the one who owns the process), and the effective user id is what the operating system looks at to make a decision whether or not you are allowed to do something (most of the time, there are some exceptions).
When you log in, the login shell sets both the real and effective user id to the same value (your real user id) as supplied by the password file.
Now, it also happens that you execute a setuid program, and besides running as another user (e.g. root
) the setuid program is also supposed to do something on your behalf. How does this work?
After executing the setuid program, it will have your real id (since you're the process owner) and the effective user id of the file owner (for example root
) since it is setuid.
The program does whatever magic it needs to do with superuser privileges and then wants to do something on your behalf. That means, attempting to do something that you shouldn't be able to do should fail. How does it do that? Well, obviously by changing its effective user id to the real user id!
Now that setuid program has no way of switching back since all the kernel knows is your id and... your id. Bang, you're dead.
This is what the saved set-user id is for.
Solution 2
I'll try to explain step by step with some examples.
Short background
Each process has its own 'Process credentials' which include attributes like PID
, the PPID
, PGID
, session ID
and also the real and effective user and group IDs:
RUID
, EUID
, RGID
, EGID
.
We'll focus on those.
Part 1: Understand UID and GID
Now I'll log into a shell with my credentials and run:
$ grep $LOGNAME /etc/passwd
rotem:x:1000:1000:rotem,,,:/home/rotem:/bin/bash
You can see my logname (rotem), the UID and GID which are both 1000, and other details like the shell I'm logged into.
Part 2: Understand RUID and RGID
Every process has an owner and belongs to a group. In our shell, every process that we'll now run will inherit the privileges of my user account and will run with the same UID and GID.
Let's run a simple command to check it:
$ sleep 10 & ps aux | grep 'sleep'
And check for the process UID and GID:
$ stat -c "%u %g" /proc/$pid/
1000 1000
Those are the real user ID (RUID
) and real group ID (RGID
) of the process.
(*) Check other options to view the UID and GID and ways to get this in a single line.
For now, accept the fact that the EUID
and EGID
attributes are 'redundant' and just equals to RUID
and RGID
behind the scenes.
Part 3: Understand EUID and EGID
Let's take the ping
command as an example.
Search for the binary location with the which
command then run ls -la
:
-rwsr-xr-x 1 root root 64424 Mar 10 2017 ping
You can see that the owner and the group of the file are root
. This is because the ping
command needs to open up a special socket and the Linux kernel demands root
privilege for that.
But how can I use ping
if I don't have root
privilege?
Notice the 's' letter instead of 'x' in the owner part of the file permission.
This is a special permission bit for specific binary executable files (like ping
and sudo
) which is known as setuid.
This is where EUID
and EGID
come into play.
What will happen is when a setuid binary like ping
executes, the process changes its Effective User ID (EUID
) from the default RUID
to the owner of this special binary executable file which in this case is - root
.
This is all done by the simple fact that this file has the setuid
bit.
The kernel makes the decision whether this process has the privilege by looking on the EUID
of the process. Because now the EUID
points to root
, the operation won't be rejected by the kernel.
Notice: On latest Linux releases the output of the ping
command will look different because of the fact that they adopted the Linux Capabilities approach instead of this setuid approach - for those who are not familiar - read here.
Part 4: What about SUID and SGID?
The Saved user ID (SUID
) is being used when a privileged process is running (as root
for example) and it needs to do some unprivileged tasks.
In that case, the effective UID (EUID
) from before will be saved inside SUID
and then changed to an unprivileged task. When the unprivileged task is completed, the EUID
will be taken from the value of SUID
and switch back to privileged account.
Solution 3
This is how I understand it. The file an user executes(equivalent to starting a process) will have a RUID equal to that user's id. Important thing to note here is that the uid which created a file is not the same as the uid that executes the file. They can be the same or different. So, RUID may vary depending on the UID that executes the file. When a file has the setuid bit on it, whenever an uid executes that file, that uid will temporary be replaced with the file owner's uid. So, if we have a file owned by uid 456 and has the setuid bit on it, whenever uid 123 executes that file, that file will be executed with the uid 456. In this scenario, uid 123 is the RUID and uid 456 is the EUID.
mohangraj
Updated on April 24, 2022Comments
-
mohangraj about 2 years
I am already aware of the real user id. It is the unique number for a user in the system.
On my system, my
uid
is$ echo $UID 1014 $
What do the other two IDs stands for?
And what is the use of effective user id and saved user id and where do we use them in the system?
-
Willem van Ketwich over 7 yearsFYI - there is also the file system user id, as outlined on the Wikipedia page: en.wikipedia.org/wiki/User_identifier
-
RtmY over 4 yearsI think he didn't mention it because (from your wiki link): "Since kernel 2.0, the existence of fsuid is no longer necessary because Linux adheres to SUSv3 rules for sending signals, but fsuid remains for compatibility reasons."
-
-
GDP2 almost 7 yearsFor more clarity on that last point about saved-set user id, see Wikipedia.
-
mik1904 over 6 yearsCan you point me to some readings where I can find which sys call check the Real uid instead? thank you
-
Damon over 6 years@mik1904: The most important one that you are likely to use which really checks real UID is
access
. That's 99.9% of it. Alsosetfsuid
(but rarely needed), and some very low level funcs, and you need (but aren't checked for) the real user ID for getting/setting priorities or scheduler, and the IDs passed to signal handlers or returned bywait
et al. are real IDs.execve
does not check, but can fail if you've changed real user id. Alsofork
does not check, but can fail if you reach the maximum process quota on the real UID. Google withsite:man7.org
is your friend here. -
Ishan De Silva about 4 yearsClear answer except for the last para on SUID. Got confused with privileged and privileged tasks. Useful if an example is provided. Thanks.
-
erik258 almost 4 years"the ping command needs to open up a socket and the Linux kernel demands root privilege for that." this isn't really accurate.
ping
needs a raw socket. any user can (usually) open a socket, and for listening, above 1024. -
Walid over 3 yearsen.wikipedia.org/wiki/User_identifier#Saved_user_ID points to a use case
-
Walid over 3 years@DanielFarrell it depends on how ping is implemented to use ICMP, tcp or udp, for icmp it requires the raw sockets and the privileges
-
KMA Badshah about 3 yearsdoes the process owner's id == RUID?? @Walid
-
rosshjb about 3 years@KMABadshah When you fork a new process, the process inherits the parent's RUID. Normally the parent's RUID is of your shell and it has a your UID. So the new process has RUID of your UID. Normally this is not changed, and only root can change it. As an example for that, think about that init process forks your login shell. During forks, the shell would have root's RUID(because the shell's parent is init). But, the init process changes the shell's RUID to your UID using
/etc/passwd
. So, thereafter the login shell's RUID would be your UID, not root. So, we can say RUID is of process owner.