Please read this long intro to understand my concern for why we need the SUID permission for executable binary file.

  • A process in Linux uses its EUID to know the effective User ID of itself.
  • This user's permission is used to decide how this process interacts with other files (ex. whether this process can write to a file)

Consider the scenario with changing password via /usr/bin/passwd

Real life Linux

  • Passwords are stored in /etc/shadow. This file belongs to root with permission (rw-------)
  • If $passwd has permission rwx--x--x, this means only root can change the logic of passwd program.
  • When userA runs the program, a passwd process starts with RUID = EUID = userA

Result is: the program will run. A passwd process is started but it won't be able to change the password since its EUID is userA and userA can't write to /etc/shadow.

This is when the need for SUID permission arrives. SUID allows setting EUID of a process upon execution of a binary to create that process. the EUID will be set to the owner of that binary file.

  • Setting SUID permission for owner of /usr/bin/passwd makes EUID of any passwd process started by any user takes the EUID of root
  • Since root can write to /etc/shadow, any user can use the passwd program to start a passwd process which can make changes to /etc/shadow

There is SUID permission because in Linux, EUID of a process is not hard set to the owner of the executable binary file (which when run, will create that process)

My ideal Linux

No need for SUID permission. If executable file binA is created (and owned) by userA, any users who can execute binA will create a process with EUID = userA.

In the context of the changing password scenario, the logic of this idea is as follows:

  • root is the owner of /usr/bin/passwd and only root can change its logic.
  • The logic inside /usr/bin/passwd lets a user change its password only and not others'.
  • Other users can't modify /usr/bin/passwd, only root can.
  • /etc/shadow can only be writen to by root

Result is: An unprivileged user userA can execute $passwd. He will create a passwd process. This process has EUID = root so it can write to the shadow file.

With this theory, we can achieve: everyone can change their own password (and only their own password) without SUID permission.

closed as off-topic by countermode, RalfFriedl, G-Man, user88036, A.B Sep 27 '18 at 1:08

  • This question does not appear to be about Unix or Linux within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    in your system where "If executable file binA is created (and owned) by userA, any users who can execute binA will create a process with EUID = userA", who should own /bin/sh and /usr/bin/vi ? – Mark Plotnick Sep 25 '18 at 10:51
  • I would say root should own. Since it's inside /bin filesystem and according to FHS, /bin is for commands that may be used by both the system administrator and by users, I think it makes sense if it is owned by root. – Tran Triet Sep 25 '18 at 10:55
  • 5
    But wouldn't that mean that anyone who ran the shell or vi would then have root permissions? – Mark Plotnick Sep 25 '18 at 10:58
  • Thank you. I see where you're pointing at, so in my system, if root owns /bin/sh or /usr/bin/vi, anyone can use vi as root and modify files only root should be able to modify. It makes perfect sense. Please give me some more time to reflect on your response and my confusion). – Tran Triet Sep 25 '18 at 11:11
  • 4
    I'm voting to close this question as off-topic because this is not a question at all but a discussion/proposal of OS features. – countermode Sep 25 '18 at 14:01

Both your examples explain how setuid works. However in your "ideal Linux" every executable would start with EUID of the owner of the executable, which would make every executable on your system a setuid executable.

This would clearly cause a lot of problems, to mention a few: every root owned executable would need to do UID checks and call setuid() to set process' EUID back to non-root if the program shouldn't have any additional privileges; users can not make executables available to another users, as the process would run with wrong EUID; configuration errors and bad practices would have critical consequences (such as chmod 777 would now also allow access to any files owned by user). And these are more.

Normal permissions without setuid binaries need some other mechanism to allow unprivileged users to do privileged operations. Setuid binaries allow such privilege elevation and access control is implemented in program logic.


The marked answer perfectly answered my question. What I put here is the extra logic that is helpful to me in explaining the existence of the SUID permission with regard to the changing password scenario.

  1. In Linux, executable bin files are supposed to be run by different users.

    For example, /usr/bin/nano is a bin for a text editor, it makes sense that this same executable bin file can be executed by different users (why make copies of the same bin file to each user's home filesystem?)

  2. Even though many users should be able to use the same bin file, the process started by that bin file should have different permissions on a file.

    For example, userA and userB should both be able to create two nano processes by executing the same /usr/bin/nano bin file. However, userA's nano process should allow userA to modify his own files and only his own files and vice versa.

This calls for a mechanism by which a process should apply the same permission that the user who started that process has on a file to that file (instead of the permission of the user who owns the executable bin file which was executed to create the process).

In Linux, each process has the RUID. The RUID is the id of the user which starts that process. By this logic, the RUID of a process should be the user whose permission on a file is used by that process (e.g. A process decides what it can do to a file based on what its RUID user can do to that file).

However, in the case of changing password, RUID alone isn't enough because:

  1. /etc/shadow file can't be modified by anyone but root.
  2. Any users want to change password need to do that through executing /usr/bin/passwd executable bin file. This program's logic makes sure an underprivileged user can change his and only his password.
  3. No users except root can change this logic since only root can write to this bin file.
  4. If userA executes /usr/bin/passwd, he will start a passwd process whose RUID is userA.
  5. However, since userA is not allowed to write to /etc/shadow, the passwd process he starts can't write to this file either.

This calls for a mechanism by which a process decides its permissions to a file based on another user's permissions on that file (instead of the permissions of the user who started the process).

In Linux, the permission a process has on a file is taken from the permission the EUID has on that file.

With EUID, root can now use SUID permission to allow userA to start a passwd process that has the EUID set to root. This effectively allows the passwd process started by userA to modify the /etc/shadow file.

Not the answer you're looking for? Browse other questions tagged or ask your own question.