为什么需要 privs 将 setgid() 设置为补充组

Question

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

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

Answer 1

当然，这里的根本难题是文件系统权限检查是基于（有效 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)。