32

I am relatively new to the concepts mentioned in the question and reading about them from different sources only makes them more confusing. So this is what I understood so far:

When we are given permissions for a file, they look like this:

-rwsr-xr-- 1 user1 users 190 Oct 12 14:23 file.bin

We assume that a user user2 who is in the group users tries to execute file.bin. If the setuid bit were not set, this would mean that both the RUID and EUID of file.bin were equal to the UID of user2. But since the setuid bit is set, this means that the RUID is now equal to the UID of user2, while EUID is the UID of the owner of the file, user1.

My questions are:

  1. What is the difference between the owner of the file and root? Does root have the same permissions as the owner? Or would we need a separate entry in the permissions list for root?
  2. Difference between RUID and EUID?
    • As I understand it the RUID and EUID are applied only to processes. If that is the case, why do they have the value of user id's?
    • If RUID is the user who creates the process, and EUID is the user who is currently running the process, then the first sentence of the first answer in this question does not make any sense to me.
    • Did I understand correctly what the setuid bit does?
Improve this question

1 Answer 1

Reset to default
47

Here are the answers:

  1. root has always full access to files and directories. The owner of the file usually has them too, but this is not always true. For example:

     -r-xr----- 1 user1 users 199 Oct 14 18:42 otherfile.bin

user1 is the owner; however they can only read and execute, but root still has full access (rwx) to the file.

  1. RUID is the Real User ID and it (almost) never changes. If user2 logs in to the system, the shell is then launched with its real ID set to user2. All processes they start from the shell will inherit the real ID user2 as their real ID.

EUID is the Effective User ID, it changes for processes (not for the user) that the user executes that have set the setuid bit.

If user2 executes file.bin, the RUID will be user2 and the EUID of the process started will be user1.

Let's use the case of passwd:

-rwsr-xr-x 1 root root 45396 may 25  2012 /usr/bin/passwd

  • When user2 wants to change their password, they execute /usr/bin/passwd.

  • The RUID will be user2 but the EUID of that process will be root.

  • user2 can use passwd to change only their own password because internally passwd checks the RUID and, if it is not root, its actions will be limited to real user's password.

  • It's neccesary that the EUID becomes root in the case of passwd because the process needs to write to /etc/passwd and/or /etc/shadow.

Improve this answer
10
  • Thank you! Now everyting is more clear. I do have one more question, though. The EUID only changes when a user executes a process which has the setuid bit set? Or can it change also in another situation? And if so, what is that situation?
    – user1956190
    Commented Mar 23, 2015 at 14:18
  • 1
    I think there is not other way than executing processes which have the setuidbit set.
    – jcbermu
    Commented Mar 23, 2015 at 14:23
  • 3
    A process that is running from a “setuid” program (i.e., a process that has Effective UID ≠ Real UID) can set the EUID back to the RUID. In some cases, it can switch the EUID back and forth between its initial value (i.e., the owner of the program file) and the RUID. Also, it may be able to set its RUID equal to its EUID. … (Cont’d)
    – Scott - Слава Україні
    Commented Mar 23, 2015 at 19:54
  • 3
    (Cont’d) … Privileged processes (those with EUID = 0, a.k.a. root) can set EUID and RUID to arbitrary values (for example, the login, su, and sudo programs do that). Generally, once a privileged process changes its UIDs to non-zero values, it is no longer privileged and cannot become root again. See the man pages setuid(2), seteuid(2), and setreuid(2).
    – Scott - Слава Україні
    Commented Mar 23, 2015 at 19:55
  • 1
    (Cont’d) …  It was introduced as a hack to solve one problem, which has subsequently been solved in a broader way.  It might have been removed from Linux except for the fact that such a pruning would break the programs that use it.  Michael Kerrisk, author of The Linux Programming Interface, says, in his version of the setfsuid(2) man page, “setfsuid() is nowadays unneeded and should be avoided in new applications.”
    – Scott - Слава Україні
    Commented Sep 6, 2018 at 20:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .