Linux 是否有任何类Unix系统将意义归于目录上的SUID位？

正如标题所说，是否有任何类Unix系统赋予目录上的SUID位以某种意义，如果是，这意味着什么

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

SGID（set GID）位的含义是-在该目录中创建的文件应属于拥有该目录的组（尽管该分配稍后可以通过显式调用chown（2））进行更改）

---

SUID位呢？

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

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

---

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

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

更新：我刚刚在Linux 2.6.25.5-1.1-default#1 SMP x86_64 GNU/Linux openSUSE 11.0（x86-64）上尝试过这个

它无效。

复制自：

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

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

---

作为Node回答的后续内容，我将从FreeBSD手册页发布以下内容以供安装（8）：

以及引用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也需要启用特殊的挂载标志，并将改变该目录中文件的行为方式。

并且您无法执行目录-那么应用于目录意味着什么呢？哦，您是对的，我忽略了目录部分。请参阅约翰·艾林伍德的答案。谢谢——这是一个有用的指针。我们是否有关于哪些系统支持“在一些系统上，目录的设置用户ID位具有类似效果”的信息？这似乎是set-group-ID特性的一个明显扩展。它会有什么安全后果？嗯，在我的linux（coreutils-5.93）上有一个好问题，它没有显示这种行为。ATM我看不出任何真正的安全问题，如果它像上面描述的那样。你知道有任何系统真正支持它吗？URL上说会发生这种情况，但我不清楚是在哪个平台上发生的。@John:你在目录上演示了SGID，而不是SUID。Solaris和Linux支持开箱即用目录上的SGID。没错。我试过4777，但它什么也没用，所以我猜OpenSuSE对它没用。Wikipedia也说只有FreeBSD使用它。SGID也可以在FreeBSD上使用，但是SUID需要内核支持和一个传递到mount的选项！谢谢-这很有帮助，因为它包含特定的平台信息。我看到的其他消息只包括这样的系统存在的一般断言。嗯，你能描述一下使用它会带来安全风险的场景吗？也许如果用户的秘密文件被创建为无人。但很高兴知道。：）upvote@Node：不确定如何将其用作安全漏洞，除此之外，它通常被视为不良做法，因此在FreeBSD/Linux中默认情况下已被禁用。注意creat（2）的第二个参数允许攻击者（Mallory）指定文件模式。假设Alice有一个setuid目录，Mallory有写权限。Mallory在此目录中创建一个文件，权限为4555（即可执行文件，SUID）。文件自动传送给Alice。Mallory pwns Alice@Martin Carpenter:FreeBSD实现已经解决了这个问题，它不允许您创建被chmod'ed为+x的文件，它总是从创建的文件中删除执行位，但它没有提到当您将setuid文件移动到setuid目录时会发生什么！

             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.

           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).