是否有任何类 Unix 系统将含义赋予目录上的 SUID 位？答案

【问题标题】：Does any Unix-like system ascribe meaning to the SUID bit on a directory?是否有任何类 Unix 系统将含义赋予目录上的 SUID 位？
【发布时间】：2009-03-10 07:48:33
【问题描述】：

正如标题所说，是否有任何类 Unix 系统为目录上的 SUID 位赋予意义，如果是，它是什么意思？

SVTX（保存的文本或粘性）位有一个含义 - 除非您可以写入文件，否则您不得从此目录中删除文件。例如，它用于 /tmp。

SGID（设置 GID）位有一个含义 - 在此目录中创建的文件应属于拥有该目录的组（尽管稍后可以通过显式调用 chown(2) 来更改该分配）。

SUID 位呢？

【问题讨论】：

标签： linux macos unix freebsd setuid

【解决方案1】：

作为 Node 回答的后续，我将在 FreeBSD 手册页中为 mount(8) 发布以下内容：

             suiddir
                 A directory on the mounted file system will respond to
                 the SUID bit being set, by setting the owner of any new
                 files to be the same as the owner of the directory.  New
                 directories will inherit the bit from their parents.
                 Execute bits are removed from the file, and it will not
                 be given to root.

                 This feature is designed for use on fileservers serving
                 PC users via ftp, SAMBA, or netatalk.  It provides secu-
                 rity holes for shell users and as such should not be used
                 on shell machines, especially on home directories.  This
                 option requires the SUIDDIR option in the kernel to work.
                 Only UFS file systems support this option.  See chmod(2)
                 for more information.

以及引用 suid 位的 chmod(2) 手册页部分：

           4000    (the setuid bit).  Executable files with this bit set will
               run with effective uid set to the uid of the file owner.
               Directories with this bit set will force all files and sub-
               directories created in them to be owned by the directory
               owner and not by the uid of the creating process, if the
               underlying file system supports this feature: see chmod(2)
               and the suiddir option to mount(8).

请注意这是一个安全风险，并且知道在 FreeBSD 中启用它时您在做什么，但我相信 Linux 也需要启用特殊的挂载标志，并且会改变该目录中文件的行为方式。

【讨论】：

谢谢 - 这很有帮助，因为它包含特定的平台信息。我看到的其他消息仅包括此类系统存在的一般断言。
嗯，您能描述一下使用它会带来安全风险的场景吗？如果来自用户的 secret 文件可能会被创建为 nobody。但很高兴知道。 :) 点赞
@Node：不知道它如何被用作安全漏洞，除了它通常被认为是不好的做法，因此它在 FreeBSD/Linux 中默认被禁用。
注意 creat(2) 的第二个参数允许攻击者 (Mallory) 指定文件模式。想象一下 Alice 有一个 setuid 目录，Mallory 有写权限。 Mallory 在此目录中创建一个权限为 4555 的文件（即可执行文件，SUID）。文件被自动 chowned 给 Alice。马洛里拥有爱丽丝。
@Martin Carpenter：FreeBSD 实现已经说明了这一点，它不允许您创建 chmod 为 +x 的文件，它总是从创建的文件中删除执行位，但它没有提到将 setuid 文件移动到 setuid 目录时会发生什么！

【解决方案2】：

复制自here:

在大多数系统上，如果设置了目录的 set-group-ID 位，则新创建的子文件会继承与目录相同的组，而新创建的子目录会继承父目录的 set-group-ID 位。在少数系统上，目录的 set-user-ID 位对新子文件的所有权和新子目录的 set-user-ID 位有类似的影响。通过减少使用 chmod 或 chown 共享新文件的需要，这些机制让用户可以更轻松地共享文件。

这些便利机制依赖于目录的 set-user-ID 和 set-group-ID 位。如果像 chmod 和 mkdir 这样的命令会定期清除目录上的这些位，那么这些机制会不太方便，并且共享文件会更加困难。因此，像 chmod 这样的命令不会影响目录的 set-user-ID 或 set-group-ID 位，除非用户以符号模式特别提及它们，或者将它们设置为数字模式。

【讨论】：

谢谢 - 这是一个有用的指针。我们是否有任何关于哪些系统支持“在少数系统上，目录的 set-user-ID 位具有类似效果”的信息？这似乎是 set-group-ID 功能的明显扩展。它会产生什么安全后果？
嗯，关于我的 linux (coreutils-5.93) 的好问题，它没有显示这种行为。 ATM 如果像描述的那样运行，我看不出任何真正的安全问题。

【解决方案3】：

当在目录上设置时，在该目录中创建的所有文件和目录都将与 SUID 目录本身具有相同的所有者，无论文件是谁创建的。这是一个不经常使用的功能，但在某些情况下它可能很有用。 (source)

更新：我刚刚在 Linux 2.6.25.5-1.1-default #1 SMP x86_64 GNU/Linux openSUSE 11.0 (X86-64) 上尝试过。

mkdir tmp
chmod 4777 tmp
su othergroup
touch testfile

没有效果。

【讨论】：

你知道实际支持它的任何系统吗 - URL 说它发生了，但我不清楚在哪些平台上。
@John：您已经在目录上演示了 SGID，而不是 SUID。 Solaris 和 Linux 支持开箱即用的目录上的 SGID。
呸，你是对的。我尝试了 4777 并没有做任何事情，所以我猜 OpenSuSE 对它没有做任何事情。 Wikipedia 还说只有 FreeBSD 也使用它。
SGID 也可以在 FreeBSD 上工作，但是 SUID 需要内核支持和一个传递给 mount 的选项！

【解决方案4】：

SUID 位表明，在执行文件时（当可执行时），进程将以所述文件所有者的身份运行，而不是执行它的用户。

在少数情况下，实用程序是“suid root”以允许权限提升。

编辑：误读原始问题（指的是目录而不是文件） - 出于教育目的保持答案不变；-)

【讨论】：

而且你不能执行目录——那么应用于目录意味着什么？
D'oh，你说得对，我忽略了目录部分。请参阅 John Ellinwood 的回答。