为什么要求privs将setgid（）添加到补充组

set*gid()除极少数情况外，各种系统调用都需要特权来更改组。将主要组更改为进程的补充组之一似乎不是其中之一，这意味着例如newgrp/ sg命令需要提升特权才能切换主要组。

是否有一个原因，为什么setgid()/ setegid()/ setregid()/ setfsgid()不允许没有PRIVS切换到补充组？如果是这样，原因是什么？

security group system-calls

— 威廉·海
source

也不确定。请注意，您可以将文件chgrp到您的一个补充组中，因此，如果您具有对没有noexec，nosuid的区域的写访问权，则可以解决该限制（通过创建/usr/bin/env具有setgid权限的副本）。

— 斯特凡Chazelas

w newgrp命令已经为我AFAICT做到了，但是生成外部程序并不总是人们想要的。

— William Hay

请注意，它newgrp/sg指的是帐户数据库，而不是流程的补充组列表。

— 斯特凡Chazelas

如果您的gid不在补充ID列表中，则允许setgid()允许您离开组的成员身份（这将是安全问题），但是同样，您也可以使用与上述相同的setgid可执行技巧来做到这一点，并且您的gid通常也位于您的补充列表中（initgroups(3)为此只需要一个gid参数）。

— 斯特凡Chazelas

Answers:

当然，这里的基本难题是文件系统权限检查基于（有效UID和）有效GID与补充GID的组合。因此，从文件权限检查的角度来看，有效GID等同于补充GID，这导致了OP的问题。（顺便说一句：如果我们谈论的是Linux，实际上是文件系统权限检查中使用的文件系统UID / GID，而不是有效的UID和GID，但是前一个ID几乎总是与后一个ID具有相同的值。）

因此，在某些情况下，实际/有效/保存设置的GID不等于补充GID。（我将真实/有效/保存集的GID分组在一起，因为正常的set * gid（）权限规则说，未特权的进程可以将这些GID中的任何一个更改为与其他两个GID相同的值。）

确实，有一些这样的情况。access（2）根据进程的真实用户ID和组ID进行检查。如果没有特权的用户能够将真实组ID更改为与不是有效或保存的集合GID的补充GID之一相同，则可以操纵access（2）的行为。

还有其他这种情况。有关示例，请参见Linux mkdir（2）手册页。根据是否在父目录上设置了set-GID模式位，在目录中创建的新文件将从创建过程的有效GID中获取其组所有权。同样，如果无特权的进程可以将其有效GID更改为其补充GID之一，则它可以以意想不到的方式操纵新文件的组所有权。类似的注释适用于mknod（2），并且System V IPC调用semget（2），shmget（2）和msgget（2）。

在某些特定于Linux的情况下，实际/有效/保存的集合GID不等于补充GID。例如，请参见process_vm_readv（2）和prlimit（2）。

— mtk
source

注意：@mtk是The Linux Programming Interface的作者。

— 斯特凡Chazelas

有效指导确定新文件的组所有权。但是之后，您可以将该组更改为您的一个辅助对象（并给setgid位，以允许您的进程有效地执行setgid（））。因此，这似乎有点虚弱。

— 斯特凡Chazelas

@StéphaneChazelas：同意，有点弱。在OTOH上，这是一个两步过程，（我现在到达这里）有可能发生奇怪的比赛。但是，除了这种情况，我上面还提到了其他情况。我不知道做出此设计决定的确切原因。也许是access（2），因为那是API的古老组成部分。当添加补充的GID时，许多其他的只是后来才出现（或特定于Linux的）或（我认为）才出现在BSD上。或者，也许，这仅仅是为了保留历史行为。我看到你补充了这一点作为答案。

— mtk

我认为原因主要是历史原因。直到4.2BSD（大约1983年）才添加补充组。在此之前，您只有真正有效的uid和gid。

setuid / setgid的行为是完全对称的，没有理由不这样做。您将使用切换用户su，并使用sg/ newgrp所有setuid可执行文件进行分组。有关用户组成员身份的信息仅驻留在用户数据库中，而不驻留在进程的属性中。

当添加辅助gid时，setuid / setgid接口未更改。

从技术上来说，现在，如果您具有对文件系统的写访问权限（未禁用执行和setuid / setgid），您仍然可以将有效或实际用户ID设置为任何辅助ID（无需诉诸sg/ newgrp仅限于btw）允许更改为用户数据库中定义的组，该组不必与该进程的辅助标识列表相同。

cp /usr/bin/env .
chgrp any-sup-group env
chmod g+s ./env

执行后env，您的egid切换到any-sup-group。

— 斯特凡·查泽拉斯
source