为什么目录上的 setuid 被忽略？

Question 1

回想一下，setuid 和 setgid 位是为了完全不同的目的而发明的：使可执行文件以其所有者的 uid 或 gid 运行，而不是以运行该文件的用户的 uid 或 gid 运行。任何其他用途都只是额外的功能。

这些位对于不可执行的普通文件不起作用。（出于安全问题，某些发行版中的 shell 脚本也是如此。）最初，它们对于目录也没有作用。显然，有人认为将未使用的 setgid 用于目录并用它来强制组所有权的一致性会很酷。毕竟，如果您使用组所有权，那是因为不止一个人在使用该文件，并且给定目录中的所有文件都属于同一组可能是合理的，无论谁创建了它们。由于有人忘记运行 newgrp 而导致的麻烦被消除了。

那么，为什么不为 setuid 和文件 uid 实现相同的功能呢？因为 uid 比 gid 更基础。如果实现此功能，文件通常将不属于创建它的用户！假设用户仍然可以修改文件（假设 umask 是合理的），但他们无法更改权限位。很难看出这样做的用处。

Answer

回想一下，setuid 和 setgid 位是为了完全不同的目的而发明的：使可执行文件以其所有者的 uid 或 gid 运行，而不是以运行该文件的用户的 uid 或 gid 运行。任何其他用途都只是额外的功能。

这些位对于不可执行的普通文件不起作用。（出于安全问题，某些发行版中的 shell 脚本也是如此。）最初，它们对于目录也没有作用。显然，有人认为将未使用的 setgid 用于目录并用它来强制组所有权的一致性会很酷。毕竟，如果您使用组所有权，那是因为不止一个人在使用该文件，并且给定目录中的所有文件都属于同一组可能是合理的，无论谁创建了它们。由于有人忘记运行 newgrp 而导致的麻烦被消除了。

那么，为什么不为 setuid 和文件 uid 实现相同的功能呢？因为 uid 比 gid 更基础。如果实现此功能，文件通常将不属于创建它的用户！假设用户仍然可以修改文件（假设 umask 是合理的），但他们无法更改权限位。很难看出这样做的用处。

Question 2

我认为这个问题的答案与“文件泄露”安全问题有关，这些问题导致大多数现代类 Unix 操作系统不允许“文件泄露”。“文件泄露”是指非超级用户将文件的所有权更改为该用户以外的其他人。此功能为恶作剧提供了许多机会。

由于不允许赠送文件，因此不允许在目录上设置 setuid（以另一种形式执行相同功能），如果设置则被忽略。

要改变行为，您必须修改操作系统库和实用程序。

Answer

我认为这个问题的答案与“文件泄露”安全问题有关，这些问题导致大多数现代类 Unix 操作系统不允许“文件泄露”。“文件泄露”是指非超级用户将文件的所有权更改为该用户以外的其他人。此功能为恶作剧提供了许多机会。

由于不允许赠送文件，因此不允许在目录上设置 setuid（以另一种形式执行相同功能），如果设置则被忽略。

要改变行为，您必须修改操作系统库和实用程序。

Question 3

实现它的一个很好的用例是：

假设您有一个多站点服务器，其中包含 3 个安全站点。您创建了 3 个组，每个组对应不同的站点维护者。所有站点中的所有文件都需要归 apache 用户所有，这样 apache 才能读取和写入它们（drupal/wordpress 等）。

如果 setuid 像目录权限的 setgid 位那样工作，则看起来像这样：

/var/www/sitea - apache:groupa  rwS rwS ---
/var/www/siteb - apache:groupb  rwS rwS ---
/var/www/sitec - apache:groupc  rwS rwS ---

这样，每组维护者都只能查看和接触自己的内容，但 Web 服务器用户 apache 可以提供所有内容，用户无需担心更改上传文件的所有权。

另一个用例是匿名 ftp/http 甚至 sftp/ssh 上传。上传目录上的组和 GID 将是 root，所有者和 UID 也是如此。其他权限将是-wx。这将允许每个人对上传目录进行写访问，但一旦上传，他们就无法读取任何内容，并且 root 将拥有所有新创建的文件。

因此，有两个非常好且有效的用例，用于启用目录上的 UID 功能以匹配 GID 位。

史蒂文·默丘里奥

Answer