执行权限有什么安全优势？

假设某些系统管理员对其用户读取 /sbin 中的文件没有问题，但不希望他们运行这些文件。举个例子

然后该管理员就消失了。任何用户都可以

cat /sbin/program > ~/program # only needs read privileges
chmod o+x ~/program
~/program

所以，这没有意义。两个例外：

1. 原始版本可能已设置 suid 位。
2. 原始版本可能有进一步限制它的安全 xattrs（SELinux、Apparmor、其他 LSM……）

第二件事无关紧要。这是相对于以用户身份执行可执行文件副本的附加限制。

首先：是的，这是个问题。但解决方案几乎无一例外地是放弃 setuid 二进制文件，转而采用进程不会获得起始用户没有的特权的机制。（你可以认为复杂的 sudo 规则是一种值得怀疑的权宜之计，但至少它有优势，因为你至少可以通过 /etc/sudoers 微调谁可以以不同用户身份执行什么。在我看来，它太容易出错了。）

这种机制在非 GNU/BSD 用户态“人机界面”操作系统（即 Android、Windows、MacOS、iOS、MBOS，仅举我想到的几个）中相当普遍：你永远不会启动“系统修改”以非特权用户身份突然获得 root 访问权限的命令，因为这只是一个寻找错误的邀请，这些错误允许您让该程序执行您想要它执行的任何操作（您可以执行您希望它们执行的任何操作的 *nix 程序的精选列表）执行）。
例如，一个流行的事情是，在科学计算服务器上，备份客户端被赋予 suid – 这样普通用户就可以将整个环境的备份运行到他们无法定期访问的存储服务中。好主意，除了能够在命令行上指定压缩器，然后以 root 身份运行之外。使用生成 telnet 服务器的脚本，否则将输入传递到未压缩的输出；完成后，你的后门就到了。

相反，有一个由 init 进程（~equivalent）产生的系统管理守护进程，非特权用户向其发送非常明确的请求，该守护进程在内部检查特权（通常使用集中机制），然后执行预配置的操作。

您的 /sbin/poweroff 示例完美地说明了这一点。对于当今的 Linux 发行版来说，关机是一个复杂的过程 - 您需要检查请求用户是否有权执行此操作，您需要检查没有其他人登录，您需要卸载已登录用户可能自己挂载的所有内容，包括网络文件系统，停止他们的用户守护进程（从他们的 emacs -d 到他们的 steam 客户端！），保存他们的工作，关闭他们的应用程序，注销他们，启动关机序列，按正确的顺序关闭所有内容（在系统 NFS 挂载仍在同步数据时不能关闭网络！）……
我可能已经有十年没有见过多用户 Linux 系统了，其中 /sbin/poweroff 只是一个 suid 关机脚本。我敢肯定 BSD 有同样的问题并以类似的方式处理它。所以，如果存在这个问题，那是因为管理员在 1990 年代中期离开了他的系统。是时候做点什么了！

Linux 桌面用户空间早已转向此。您的 Linux 桌面不再调用 Suid 来mount挂载您刚插入并想要以非特权用户身份打开的 USB 记忆棒，而是请求从磁盘管理守护进程访问。运行良好（并且，经过实践，它比 90 年代末/2000 年代初的 Linux 更可靠、更友好、更不容易出错）。

那么，回到你的问题：

那么执行特权的意义是什么？

它允许您限制哪些文件可以立即执行。如前所述，SUID 和其他文件绑定安全机制的存在会产生影响；它会影响您是否可以使用某些东西作为文件格式的解释器，并且它会告诉您的 shell，当您键入“nano”时，您希望执行 /usr/bin/nano，而不是名为“的文本文件” nano”恰好结束在您路径中的其他地方。

文件的执行权限位并不是真正的安全功能，它主要用于区分可执行文件和不可执行文件。

执行安全性由其他系统功能处理。例如，不想允许用户运行任意二进制文件的管理员可以确保用户可以写入的任何目录都位于noexec安装点上。权限提升（例如 setuid 二进制文件）依赖于复制二进制文件时丢失的属性：setuid 位、配置文件（例如sudoers或pkexec配置文件）中的条目等。

那么执行特权的意义是什么？

主要是它可以防止无意中执行实际上不包含可执行代码或脚本的文件。诸如README.txt.

您认为拒绝程序文件的执行权限同时允许用户读取它是徒劳的，这是绝对正确的：用户可以读取的任何内容，他们都可以复制；新副本将归他们所有，可以根据他们的需要设置权限。

但在某些情况下，您可能希望授予执行权限，而不授予相应的读取权限。一个示例可能是分配有 setuid/setgid 权限的程序。一些专有的 Unix 系统（以及一些强化指南）可能会将权限设置/bin/passwd为---s--x--x，所有者root，以阻止用户尝试通过使用反汇编程序或其他调试工具来查找 setuid 二进制文件中的弱点。

在 Linux 和 BSD 等开源操作系统中，这种对权限的微观管理可以被认为是不必要的，因为这些 setuid/setgid 程序的源代码无论如何都可以免费提供给任何人。

即便如此，内核和驱动程序仍然规定哪些操作需要比普通用户更多的权限。/sbin/ifconfig以普通用户身份访问可执行副本可能允许您查看系统的网络设置，但如果您尝试更改它们，您将得到的只是一条“权限被拒绝”错误消息。

如果你尝试复制 setuid 或 setgid 二进制文件，你会发现许多文件系统驱动程序在写入文件时会自动删除这些权限位，因此在写入完成后需要明确放回这些位……但如果没有 root (或同等) 权限，你绝对不能生成除你自己的用户帐户之外任何人拥有的新文件，因此即使你可以保留或重新添加 setuid 位，副本也不会是 setuid root，而是 setuid yourself。它不会授予你任何你没有的权限，并且拥有它可能允许其他用户冒充你。

setgid 位也是如此：如果您尝试将 setgid 位添加到您的用户帐户还不是其成员的组所拥有的文件中，则添加 setgid 位的请求将被默默忽略。

看man 2 chmod：

如果调用进程没有特权（Linux：没有 CAP_FSETID 能力），并且文件的组与进程的有效组 ID 或其补充组 ID 之一不匹配，则 S_ISGID 位将被关闭，但这不会导致返回错误。