这个setuid概念似乎逐渐过时，在少数仍在使用的情况下被适当的权限和身份验证模型所取代。例子：
ping已转换为使用能力，mount正在被取代udisks，- SSH 可以替代
su和sudo。
在我输入这些单词的系统上，我发现了 18 个带有suid位设置的二进制文件，其中大多数是为另一个程序切换用户上下文的任务的变体（su、
sg、pkexec等）和mount（正常和熔断）。他们似乎都不是不可替代的。
那么，哪些任务suid还需要该位呢？
答案1
Ping 已从 setuid root 移至 setcap net_admin。如果程序表现出意外行为，从 setuid root 迁移到 setcap 可以降低风险。但这是相同的基本机制：进程根据实例化的可执行文件中的元数据接收额外的权限。这个概念并没有过时，而是在不断完善。
这并不是一个新现象：减少授予程序的特权数量是一个长期趋势。二十年前，除 root 之外的用户的可执行文件 setuid 很常见，但（操作系统权限模型没有任何变化）这些实际上已经消失了。如今，需要访问额外文件权限的可执行文件被设置为 setgid，而不是 setuid，因此，如果它们受到损害，攻击者获得的权限不会超过该程序所拥有的权限。 setuid 可执行文件的危险在于，如果它被泄露，攻击者可以用特洛伊木马替换可执行文件的内容，从而危及执行该程序的任何人的帐户。
还有一种长期趋势是不让程序设置 setuid 或 setgid，而是授予用户通过 sudo 执行它们的权限。 Sudo 的优点是更细粒度的控制（谁可以执行程序，以及可以将哪些参数传递给程序），更容易在网络上部署（只需部署配置文件/etc/sudoers，而不必在安装时小心权限） 、升级和部署程序）以及日志记录。
Mount 需要 setuid root 来让非 root 用户挂载分区。它确实可以被其他程序取代，例如pmount（它本身需要 setuid root）或基于服务的机制，例如 udisks。
实际上只有两个程序绝对必须是 setuid root：su和sudo。 （以及任何其他类似的程序。）由于它们必须能够授予任何权限，因此它们必须拥有系统中的最高权限。
SSH 不能完全替代 su 和 sudo。 SSH 可以用作权限升级机制，但它并不适合所有情况。 SSH 会话中的所有内容都通过隧道。这并不总是可取的：您无法通过 SSH 通道传递文件描述符或共享内存，这会造成性能损失（SSH 会加密数据，即使在本地通信时也是如此）。此外，如果 SSH 守护程序崩溃或配置错误，对于想要修复系统的系统管理员来说，SSH 毫无用处。
¹或 setcap sys_admin，但成为 root 和您可以使用该特权间接执行的操作之间没有真正的区别sys_admin- 例如使用 setuid root 二进制文件安装分区或通过/etc或挂载某些内容/bin。