为什么在目录上忽略setuid？

在Linux系统上，您可以成功完成chmod u+s $some_directory，但是您可以u+s像期望的那样，不强迫新的子目录和文件的所有权成为包含目录（以及设置子目录）的所有者，而只是忽略setuid位。子目录和文件继续继承其创建过程的UID，默认情况下，子目录不是setuid。

为什么setuid在目录上被忽略，如何使系统识别它？

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

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

那么，为什么不为setuid和文件uid实现相同的功能呢？好吧，uid比gid更基本。如果执行此操作，则文件通常不属于创建它的用户！大概用户仍然可以修改文件（假设umask是合理的），但是他们不能更改权限位。很难看到它的效用。

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

由于不允许文件泄露，因此不允许目录上的setuid以其他形式执行相同功能，如果设置，则将其忽略。

至于更改行为，则必须修改OS库和实用程序。

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

假设您有一台包含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也将是root。其他权限为-wx。这样一来，每个人都可以WRITE访问上载目录，但是一旦上载目录，他们将无法读取任何内容，而root将拥有新创建的所有文件。

因此，有两个完全有效的用例，用于在目录上启用UID功能以匹配GID位。

史蒂文·莫库里奥（Steven Mercurio）

晚会晚了一点，但是万一以后的读者偶然发现了这个问题；）如其他人所述，在标准的OS-X文件系统上，目录的setUID被忽略了-似乎没有一种简便的方法（mount -o....或其他什么）。通常，手册页实际上不符合其字面陈述的OS-X行为：

4000（执行时设置用户ID）位设置了用户ID的目录将强制所有在其中创建的文件和子目录归目录所有者而非所有者所有创建过程的uid [...]

但它也列出了在不放弃原始所有权的情况下达到相同效果的可能性。Linux使用'[g /] setfacls'来达到类似的效果（乍一看，它们的权限并不真正可见，因此有时可能会令人讨厌）。

关于“如何实现类似的效果”，请阅读整个手册页并摆弄：

chmod +a 'guest allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' ./[DIRECTORY]

你可以通过检查

ls -le

如果一切都很好。其他选项包括在特定位置插入规则，删除或替换特定规则。这里的两个值得注意的选项是“ file_inherit和directory_inherit”，允许将规则附加到新目录/文件。

我不太喜欢使用setUID，但是setGID在文件服务器上非常方便，在文件服务器上，仅设置'main'组不起作用，或者客户端具有禁止组写的文件掩码。可以通过以下方法解决：

chmod +a 'mygroup allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /fileserver/groupfolders/mygroup

好吧，它应该尊重标准。我可以在仅使用sftp的许多场景中考虑一下，这将为我省去很多麻烦，无论是acl还是sshd的acl-mask-set以及我必须对该掩码进行的重置。

默认情况下，安全性是非常有用的，但是如果您不选择它，那么您只是在创建翼箭。

https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

无论哪种方式，它都像Linux现在一样，因此只需使用acl来解决这些问题。

根据http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories的说明，UNIX和Linux系统上的目录都将忽略setuid位。可以使其在FreeBSD上按预期的方式运行。