The setuid concept appears to become gradually obsolete, being replaced by proper permissions and authentication models in the few cases it is still in use. Examples:

  • ping has been converted to use capabilities,
  • mount is being superseded by udisks,
  • SSH can replace su and sudo.

On the system I type these words, I found 18 binaries with the suid bit set, most of them variations over the task of switching the user context for another program (su, sg, pkexec, etc.) and mount (normal and fuse). None of them seem to be irreplaceable.

For what tasks is the suid bit still required then?

closed as primarily opinion-based by Rui F Ribeiro, Hauke Laging, Kusalananda, dirkt, DarkHeart Mar 11 '18 at 23:10

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 7
    SSH can not replace su and sudo on systems where root logins are sensibly disallowed (it would also be weird to have startup scripts and cron jobs SSH to localhost just to assume the identity of another system user). Also, should this question maybe be tagged with the linux tag as it seems to assume Linux? – Kusalananda Mar 11 '18 at 9:50
  • udisks has been giving me nothing but trouble over the years (e.g. endless hardware reset loops when trying to read audio CDs via a wonky SATA-IDE bridge), and the day mount is "obsoleted" by it is the day I'll stop using Linux... – dirkt Mar 11 '18 at 15:13
  • @Kusalananda “SSH can not replace su and sudo on systems where root logins are sensibly disallowed” Those permission configurations could be mapped to selinux and the likes. I don’t see how root-through-setuid is a prerequisite. – Philipp Gesang Mar 11 '18 at 17:24
  • @dirkt Just because there are issues with the current implementation of udisks (which I’m not awfully happy with myself) doesn’t imply that mount has no alternative. – Philipp Gesang Mar 11 '18 at 17:27

Ping has moved from setuid root to setcap net_admin. Moving from setuid root to setcap reduces the risks if the program exhibits unintended behavior. But that's the same basic mechanism: a process receives extra privileges based on metadata in the executable that it's instantiated from. The concept isn't obsolete, it's being refined.

This is not a new phenomenon: there's a long trend of reducing the amount of privileges conferred to programs. Twenty years ago, executables setuid to a user other than root were common, but (without any change in the OS permission model) those have practically disappeared. Nowadays executables that require the permission to access extra files are made setgid, not setuid, so that if they are compromised, the attacker gains no more than the privileges the program has. The danger of a setuid executable is that if it is compromised, the attacker can replace the content of the executable by a Trojan that will compromise the account of anyone who executes the program.

There is also a long trend towards not making programs setuid or setgid, but rather giving users the permission to execute them via sudo. Sudo has the benefit of finer-grained control (over who can execute the program, and over what arguments can be passed to the program), easier deployment on networks (simply deploy the configuration file /etc/sudoers, rather than having to be careful about permissions when installing, upgrading and deploying the program), and logging.

Mount needs to be setuid root¹ to let non-root users mount partitions. It can indeed be replaced by other programs such as pmount (which itself needs to be setuid root) or a service-based mechanism such as udisks.

There are really only two programs that absolutely positively must be setuid root: su and sudo. (And any other similar program.) Since they must be able to grant any privilege, they must have the highest privilege in the system.

SSH cannot completely replace su and sudo. SSH can be used as a privilege escalation mechanism, but it isn't suitable for all circumstances. Everything in an SSH session goes through a tunnel. This is not always desirable: you can't pass file descriptors or shared memory via an SSH channel, there is a performance loss (SSH encrypts data, even when talking locally). Also, SSH is useless for a system administrator who wants to repair the system if the SSH daemon has crashed or has been misconfigured.

¹ or setcap sys_admin but there's no real differences between being root and what you can do indirectly with the sys_admin privilege — such as mounting a partition with a setuid root binary or mounting something over /etc or /bin.

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