最近在部署到新的（Solaris 9）环境时，其中一个步骤是将一组文件和目录复制到新位置，然后应用组 UID 位（使用“chmod -R g+s” ) 到目录树中的所有文件，为所有内容提供 -rwxr-s--- 模式。结果是，除非单独打开并重新保存它们，否则我们的任何 shell 脚本都不会执行。我应该补充一点，我们之前在复制文件之前已经在目标父文件夹上设置了 g+s；这已将所有新目录的初始模式设置为 drwxr-s--- 但文件的模式为 -rwxr-x---
在最终发现是哪个步骤导致问题后，我们能够删除该步骤并继续进行。
然而，我想了解“s”位应用于目录和文件时的含义，希望这将解释为什么我们首先会遇到问题。
【问题讨论】：
设置目录 g+s 使在该目录中创建的所有新文件都将其组设置为目录的组。
如果您设置了 umask 以便文件默认具有组写入功能，这实际上对于协作目的非常方便。
注意：这是它在 Linux 中的工作方式，它在 Solaris 中的工作方式可能完全不同。
【讨论】：
对于可执行文件，这意味着当文件被执行时，它是作为拥有该文件的组执行的，而不是执行该文件的用户的组。
如果您希望用户能够假设某个特定组的权限只是为了运行一个命令，这将非常有用。
但是，这也是一个安全风险，因为它允许用户提升他们的权限。你必须知道设置了这个位的脚本不会做任何让用户滥用这些额外权限的事情。
【讨论】：
这里是 SGID (chmod g+s) 的非常方便的解释：http://www.linuxnix.com/sgid-set-sgid-linuxunix/
SGID（在执行时设置组 ID）是一种特殊类型的文件 授予文件/文件夹的权限。通常在 Linux/Unix 中，当 程序运行时，它从登录用户那里继承访问权限。 SGID 被定义为授予用户临时权限以运行 program/file 具有文件组权限的权限 成为该组的成员以执行该文件。简而言之，用户 执行时将获得文件组的权限 文件夹/文件/程序/命令。
【讨论】：
对于可执行文件，g+s 会覆盖可执行文件将作为其运行的组 ID（它通常继承自父级）。
$ cp `which id` id-test $ ./id-test uid=1001(user1) gid=1001(group1) groups=1001(group1),2001(project1) $ chgrp project1 id-test $ chmod g+s 身份测试 $ ./id-test uid=1001(user1) gid=1001(group1) egid=2001(project1) groups=1001(group1),2001(project1)
（egid 是“有效组 id”——通常与 gid、“组 id”相同，但这里不同。）
对于目录，g+s 会覆盖新文件和目录将拥有的组 ID（通常从创建者那里继承）。
$ mkdir 项目 $ chgrp project1 文件1 $ 掩码 0022 $ 触摸项目/文件1 $ ls -l 项目/文件1 -rw-r--r-- 1 用户 1 组 1 0 文件 1 $ chmod g+s 项目 $ 触摸项目/文件2 $ ls -l 项目/文件2 -rw-r--r-- 1 user1 project1 0 file2
您可能仍需要摆弄umask 以获得最佳效果；共享写入需要至少与0007 一样宽松的内容，共享阅读需要至少与0027 一样宽松的内容。
$ umask 0077 $ 触摸项目/文件3 $ ls -l 项目/文件3 -rw------- 1 用户 1 项目 1 0 文件 3 $ umask 0027 $ 触摸项目/文件4 $ ls -l 项目/文件4 -rw-r----- 1 用户 1 项目 1 0 文件 4 $ umask 0007 $触摸项目1/文件5 $ ls -l 项目1/文件5 -rw-rw---- 1 user1 project1 0 file5
【讨论】：
对于文件，这意味着文件作为拥有文件的组执行，而不是执行文件所属的组用户。当你想允许用户做他没有权限的事情时，它是有用的。例如，对于我使用的一个 DBMS，通常允许每个人备份数据库。虽然只有 'dbms' 组对数据库文件具有读/写权限，但备份程序设置了 g+s 以允许任何人通过它访问数据库，但不能直接访问。
对于目录，这意味着新创建的目录将归拥有该目录的组所有，而不是创建文件所属的组用户。一个很好的例子是 sourceforge.net 项目的网络空间。想象一下 3 个开发人员维护项目网站。现在，如果其中一个人创建了一个文件，则只有他可以写入（默认情况下）。为了解决这个问题，同一个项目的所有用户也都在同一个组中，并且目录对该组具有 rws 权限，因此无论谁创建文件，它都会被创建为对该组可读和可写。
【讨论】：
更多关于 setuid 和 setgid 的信息here
【讨论】：
为了稍微扩展您的具体问题，已经注意到 sgid 可执行文件可能会通过授予用户通常没有的权限而导致问题。虽然这对于任何可执行文件都是一个问题，但它会在脚本（特别是“通过文件开头的 #! 标识的外部解释器执行的文件”）的情况下创建一个潜在可利用的竞争条件，这可以用于执行具有脚本权限的任意代码。
多年来，Unix 衍生产品实施了许多旨在减轻或消除此漏洞的方案，其中大多数包括某种形式的完全禁止执行 suid 或 sgid 脚本或要求您跳过一些障碍启用它（通常在逐个脚本的基础上）。一种这样的方案将导致您在打开脚本的 sgid 标志后无法运行脚本。
【讨论】：
当你需要使用它时：修复使用 svn+ssh 时的 SVN 文件所有权问题。有人告诉我它只发生在 BDB 上，但我在 FSFS 存储中也遇到了这样的问题。基本上，当您希望在有其他用户在其上写东西的情况下保持目录内子文件的所有权一致时，您将不得不使用 u+s/g+s。
【讨论】：