33

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

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

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

4

8 回答 8

77

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

如果您设置了 umask 以便文件默认具有组写入功能，这实际上对于协作目的非常方便。

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

于 2008-10-10T12:47:32.083 回答
12

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

如果您希望用户能够假定特定组的权限仅用于运行一个命令，这将很有用。

然而，这也是一个安全风险，因为它允许用户提升他们的权限。你必须知道设置了这个位的脚本不会做任何让用户滥用这些额外权限的事情。

于 2008-10-10T12:39:11.727 回答
7

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

SGID（在执行时设置组 ID）是赋予文件/文件夹的一种特殊类型的文件权限。通常在 Linux/Unix 中，当程序运行时，它会从登录用户那里继承访问权限。SGID 被定义为授予用户临时权限以运行具有文件组权限的程序/文件的权限，使其成为该组的成员以执行文件。简而言之，用户在执行文件夹/文件/程序/命令时将获得文件组的权限。

于 2012-03-20T13:18:33.503 回答
5

对于可执行文件，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 用户 1 项目 1 0 文件 2

您可能仍然需要摆弄以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 用户 1 项目 1 0 文件 5
于 2008-10-10T15:10:36.087 回答
2

对于文件，这意味着文件作为拥有文件的组执行，而不是执行文件所属的组用户。当你想允许用户做他没有权限的事情时，它是有用的。例如，对于我使用的一个 DBMS，通常允许每个人备份数据库。虽然只有 'dbms' 组对数据库文件具有读/写权限，但备份程序设置了 g+s 以允许任何人通过它访问数据库，但不能直接访问。

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

于 2008-10-10T13:05:33.327 回答
0

有关 setuid 和 setgid 的更多信息在这里

于 2008-10-10T12:42:12.173 回答
0

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

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

于 2008-10-10T18:14:10.227 回答
0

需要使用时：修复使用 svn+ssh 时的 SVN 文件所有权问题。有人告诉我它只发生在 BDB 上，但我在 FSFS 存储中也遇到了这样的问题。基本上，当您希望在有其他用户在其上写入内容时保持目录内子文件的所有权一致时，您将不得不使用 u+s/g+s。

于 2008-10-10T18:16:46.383 回答