mjhjmtu

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.

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.