1

I am trying to find the correct reason for the stated question. My understanding is that:

  • sudo needs to read the /etc/sudoers file which is only readable by root, which is why it needs to be set-UID root
  • su is going to create a new shell with a different real and effective UID, and needs to check the password. To check the password, it needs to read /etc/shadow, which is why it needs to be set-UID root. After checking password, it would need to call setuid() on the forked process, and to use an arbitrary UID argument, its parent process must have root as effective UID, so this also makes another reason.

Are the above reasons correct ?

terdon
  • 242,166
Jake
  • 1,353

1 Answers1

6

Your reasons are mostly correct, but in both cases (su and sudo), the basic reason they need to run as root, is that they need to be able to change the various user and group identifiers of the current process. This involves calling functions such as setreuid, which only work for arbitrary users and groups if the calling process is running as root.

Both su and sudo have other features which also require running as root, but they are effectively secondary details when compared to the above. As you mention, sudo needs to read /etc/sudoers; but the fact that the latter is readable only by root isn’t a hard requirement. Both programs can use PAM to perform authentication, but they typically also include fallbacks which require being able to read /etc/shadow, which is also only readable by root. The list goes on; but it doesn’t really matter since the inescapable fact is that the ability to change users and/or groups is only given to root, which is why su and sudo are setuid root.

How do the internals of sudo work? and the related questions give additional background.

Stephen Kitt
  • 434,908