我什么时候可以或应该在文件或目录上使用 chmod g+s ？
最近部署到新的 (Solaris 9) 环境时，其中一个步骤是将一组文件和目录复制到新位置，然后将组 UID 位（使用“chmod -R g+s”）应用于所有文件和目录目录树中的文件为所有内容提供 -rwxr-s--- 模式。 结果是，除非单独打开并重新保存，否则我们的 shell 脚本都不会执行。 我应该补充一点，在复制文件之前，我们已经在目标父文件夹上设置了 g+s； 这已将所有新目录的初始模式设置为 drwxr-s--- 但文件的模式为 -rwxr-x---
最终发现导致问题的步骤，我们能够删除该步骤并继续。
然而，我想了解“s”位在应用于目录和文件时的含义，希望这能解释为什么我们首先遇到问题。
In deploying to a new (Solaris 9) environment recently, one of the steps was to copy a set of files and directories to their new location and then to apply the group UID bit (using "chmod -R g+s") to all files in the directory tree giving a mode of -rwxr-s--- to everything. The result was that none of our shell scripts would execute unless they were individually opened and re-saved. I should add that we had earlier set g+s on the target parent folder prior to copying files; this had set the initial mode on all the new directories to drwxr-s--- but the files had a mode of -rwxr-x---
Having eventually discovered which step caused the problem, we were able to cut out that step and proceed.
I would like, however, to understand what the "s" bit means when applied to directories and files, in the hope that this will explain why we had the problem in the first place.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
设置目录 g+s 会使在该目录中创建的所有新文件的组设置为该目录的组。
如果您设置了 umask 以便文件默认进行组写入，这实际上对于协作目的非常方便。
注意：这是在 Linux 中的工作方式，在 Solaris 中的工作方式可能完全不同。
Setting directories g+s makes all new files created in said directory have their group set to the directory's group.
This can actually be really handy for collaborative purposes if you have the umask set so that files have group write by default.
Note: This is the way it works in Linux, it could work completely differently in Solaris.
对于可执行文件，这意味着当执行该文件时，它是作为拥有该文件的组执行的，而不是作为执行该文件的用户的组执行的。
如果您希望用户能够承担特定组的权限以运行一个命令，那么这非常有用。
然而，这也是一个安全风险，因为它允许用户提升权限。 您必须知道设置了此位的脚本不会执行任何会让用户滥用这些额外权限的操作。
For executable files, this means that when the file is executed, it is executed as the group that owns the file, not the group of the user executing the file.
This is useful if you want users to be able to assume the permissions of a particular group just for running one command.
However, it is also a security risk as it is allowing users to elevate their permissions. You have to know that the scripts with this bit set aren't going to do anything that would let users abuse these extra permissions.
这是 SGID (chmod g+s) 的非常方便的解释：http://www. linuxnix.com/sgid-set-sgid-linuxunix/
Here is very handy explanation of SGID (chmod g+s): http://www.linuxnix.com/sgid-set-sgid-linuxunix/
对于可执行文件，
g+s会覆盖可执行文件将运行的组 ID（通常是从父级继承的）。（egid 是“有效组 id”——通常与 gid、“组 id”相同，但这里不同。）
对于目录，
g+s会覆盖新文件和目录将要使用的组 id有（通常是从创建者那里继承的）。您可能仍然需要摆弄
umask以获得最佳结果； 共享写入需要至少与0007一样宽松的内容，共享读取至少需要与0027一样宽松的内容。For a executable,
g+soverrides the group id that the executable will run as (it is usually inherited from the parent).(egid is "effective group id" -- usually the same as gid, "group id", but here different.)
For a directory,
g+soverrides the group id that new files and directories will have (it is usually inherited from the creator).You may still need to fiddle with
umaskfor best results; something at least as permissive as0007is required for shared writing, and something at least as permissive as0027is required for shared reading.对于文件来说，这意味着文件是作为拥有该文件的组执行的，而不是执行该文件所属的组用户。 当您想要允许用户执行他没有权限的操作时，它非常有用。 例如，对于我使用的一种 DBMS，允许每个人备份数据库是很常见的。 虽然只有“dbms”组具有对数据库文件的读/写访问权限，但备份程序已将 g+s 设置为允许任何人通过它访问数据库，但不能直接访问。
对于目录，这意味着新创建的目录将由拥有该目录的组拥有，而不是创建该文件所属的组用户。 sourceforge.net 项目的网络空间就是一个很好的例子。 想象一下 3 个开发人员维护项目网站。 现在，如果其中一个创建了一个文件，则只有他可以写入该文件（默认情况下）。 为了解决这个问题，同一项目上的所有用户也都在同一组中，并且目录对该组具有 rws 权限，因此无论谁创建该文件，它都会被创建为该组可读和可写的。
For files it means that the file is executed as the group that owns the file, not the group user that executes the file belongs to. It is usable when you want to allow user to do something which for which he does not have the privilege. For example, for one DBMS I use, it is common to allow everybody to backup databases. Although only the 'dbms' group has read/write access to database file, the backup program has g+s set to allow anyone to access the database through it, but not directly.
For directories, it means that newly created directories will be owned by the group that owns the directory, not the group user that created the file belongs to. A good example for this is web space of sourceforge.net project. Imagine 3 developers maintaining the project website. Now, if one of them creates a file, only he can write to it (by default). To work around this, all users on the same project are in the same group as well, and directory has rws privilege for that group, so whoever creates the file, it gets created as readable and writable to the group.
有关 setuid 和 setgid 的更多信息此处
More information about setuid and setgid here
为了稍微扩展一下您的具体问题，已经注意到 sgid 可执行文件可能会通过授予用户通常没有的权限而导致问题。 虽然这对于任何可执行文件来说都是一个问题，但它在脚本（特别是指“通过文件开头由 #! 标识的外部解释器执行的文件”）的情况下创建了一个潜在可利用的竞争条件，这可以用于以脚本的权限执行任何任意代码。
多年来，Unix 衍生版本已经实施了许多旨在减轻或消除此漏洞的方案，其中大多数都包括某种形式的完全禁止执行 suid 或 sgid 脚本，或者要求您跳过一些步骤才能启用它（通常基于逐个脚本）。 其中一种方案可能会导致您在打开 sgid 标志后无法运行脚本。
To expand on your specific problem a little, it has already been noted that sgid executables can cause problems by granting users permissions they don't normally have. While this is an issue for any executable, it creates a potentially-exploitable race condition in the case of scripts (specifically meaning "files which execute by means of an external interpreter identified by a #! at the beginning of the file") which can be used to execute any arbitrary code with the script's permissions.
Unix deriviatives have implemented a number of schemes over the years which are aimed at mitigating or eliminating this vulnerability, most of which have included some form of prohibiting the execution of suid or sgid scripts entirely or requiring you to jump through a few hoops to enable it (usually on a script-by-script basis). One such scheme would be the cause of your inability to run the scripts after turning on their sgid flag.
当你需要使用它时： 修复使用 svn+ssh 时的 SVN 文件所有权问题。 有人告诉我这只发生在 BDB 上，但我在 FSFS 存储中也遇到了这样的问题。 基本上，当您希望在其他用户在其上写入内容时保持目录内子文件的所有权一致时，您必须使用 u+s/g+s。
When you need to use it: Fix SVN file ownership issue when you use svn+ssh. Somebody told me it only happens on BDB, but I had such issue in FSFS storage too. Basically when you want to keep the ownership of child files inside a directory consistent when there are other users writing stuff on it, you would have to use u+s/g+s.