☰

为什么需要 privs 来 setgid() 到补充组

tag-icon • tag-icon security group system-calls
为什么需要 privs 来 setgid() 到补充组

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

setgid()///是否有理由setegid()不允许切换到没有权限的补充组？如果是的话，原因是什么？setregid()setfsgid()

答案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) 的行为。

还有其他类似的情况。参见Linuxmkdir(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)。

答案2

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

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

当添加补充gids时，setuid/setgid接口没有改变。

从技术上讲，现在，如果您对文件系统具有写访问权限（其中执行和 setuid/setgid 未禁用），您仍然可以将有效或真实用户 ID 设置为任何补充 gid（无需求助于sg/newgrp顺便说一句）允许更改为用户数据库中定义的组，该组不一定与进程的补充 gids 列表相同）。

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

执行后env，您的 epid 切换到any-sup-group.

相关内容