什么时候可以或者我应该在文件或目录上使用chmod g + s？

Question

最近部署到新的（Solaris 9）环境时，其中一个步骤是将一组文件和目录复制到新位置，然后应用组UID位（使用“chmod -R g + s”） ）对目录树中的所有文件给出一切-rwxr-s模式。结果是，除非单独打开并重新保存，否则我们的shell脚本都不会执行。我应该补充一点，我们之前在复制文件之前在目标父文件夹上设置了g + s;这已经将所有新目录的初始模式设置为drwxr-s ---但文件的模式为-rwxr-x ---

最终发现哪个步骤导致了问题，我们能够切断该步骤并继续。

但是，我想了解“s”位在应用于目录和文件时的含义，希望这能解释为什么我们首先遇到问题。

Answer 1

设置目录g + s使得在所述目录中创建的所有新文件都将其组设置为目录的组。

如果你设置了umask，那么这对于协作来说实际上非常方便，因此默认情况下文件都有组写。

注意：这是它在Linux中的工作方式，它可以在Solaris中完全不同。

Answer 2

对于可执行文件，这意味着在执行文件时，它将作为拥有该文件的组执行，而不是执行该文件的用户组。

如果您希望用户能够仅为运行一个命令而承担特定组的权限，这将非常有用。

但是，它也存在安全风险，因为它允许用户提升其权限。您必须知道具有此位设置的脚本不会执行任何会让用户滥用这些额外权限的操作。

Answer 3

这是SGID（chmod g + s）的非常方便的解释：http://www.linuxnix.com/sgid-set-sgid-linuxunix/

  

SGID（执行时设置组ID）是一种特殊类型的文件   赋予文件/文件夹的权限。通常在Linux / Unix时   程序运行时，它继承了登录用户的访问权限。   SGID定义为为用户提供临时权限以运行   程序/文件具有文件组权限的权限   成为该组的成员来执行该文件。简单来说就是用户   执行时将获得文件组的权限   文件夹/文件/节目/命令。

Answer 4

对于可执行文件，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
$ ./id-test
uid=1001(user1) gid=1001(group1) egid=2001(project1) groups=1001(group1),2001(project1)

（egid是“有效群组ID” - 通常与gid相同，“群组ID”，但此处不同。）

对于目录，g+s会覆盖新文件和目录将具有的组ID（通常从创建者继承）。

$ mkdir project
$ chgrp project1 file1
$ umask
0022
$ touch project/file1
$ ls -l project/file1
-rw-r--r-- 1 user1 group1 0 file1
$ chmod g+s project
$ touch project/file2
$ ls -l project/file2
-rw-r--r-- 1 user1 project1 0 file2

您可能仍需要摆弄umask以获得最佳效果;共享写作需要至少与0007一样宽松的东西，共享阅读需要至少与0027一样宽松的东西。

$ umask 0077
$ touch project/file3
$ ls -l project/file3
-rw------- 1 user1 project1 0 file3
$ umask 0027
$ touch project/file4
$ ls -l project/file4
-rw-r----- 1 user1 project1 0 file4
$ umask 0007
$ touch project1/file5
$ ls -l project1/file5
-rw-rw---- 1 user1 project1 0 file5

Answer 5

对于文件，它表示文件作为拥有该文件的组执行，而不是执行该文件所属的组用户。当您希望允许用户执行他没有权限的操作时，它可用。例如，对于我使用的一个DBMS，通常允许每个人备份数据库。虽然只有'dbms'组对数据库文件具有读/写访问权限，但备份程序的g + s设置为允许任何人通过它访问数据库，但不能直接访问数据库。

对于目录，这意味着新创建的目录将归拥有该目录的组所有，而不是创建该文件所属的组用户。一个很好的例子是sourceforge.net项目的web空间。想象一下3位开发人员维护项目网站。现在，如果其中一个文件创建了一个文件，那么只有他可以写入文件（默认情况下）。要解决此问题，同一项目中的所有用户也在同一个组中，并且目录对该组具有rws特权，因此无论谁创建该文件，它都会被创建为对组可读和可写。

Answer 6

有关setuid和setgid here

的详细信息

Answer 7

为了稍微扩展您的特定问题，已经注意到sgid可执行文件可能会通过授予用户通常不具有的权限来导致问题。虽然这是任何可执行文件的问题，但在脚本的情况下（特别是“通过文件开头的＃！标识的外部解释器执行的文件”），它会创建一个潜在可利用的竞争条件。用于执行任何具有脚本权限的任意代码。

多年来，Unix衍生产品已经实施了许多旨在减轻或消除此漏洞的方案，其中大部分都包含某种形式的禁止完全执行suid或sgid脚本或要求您跳过几个环节启用它（通常是逐个脚本）。一个这样的方案将导致您在打开sgid标志后无法运行脚本。

Answer 8

当您需要使用它时：使用svn + ssh修复SVN文件所有权问题。有人告诉我它只发生在BDB上，但我在FSFS存储中也有这样的问题。基本上，当您希望将子文件的所有权保留在目录中时，如果有其他用户在其上写东西，则必须使用u + s / g + s。