☰

echo 到 gid_map 失败但 uid_map 成功

tag-icon • tag-icon linux-mint namespace unshare
echo 到 gid_map 失败但 uid_map 成功

我试图通过写入 uid_map 和 gid_map 文件来映射新命名空间中的用户和组 ID。

很快1号航站楼我正在做

vaibhav@vaibhav:~$ unshare -U /bin/sh
$ id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
$ echo $$
2506

然后我打开新终端即2 号航站楼我做

vaibhav@vaibhav:~$ echo '0 1000 1' > /proc/2506/
uid_map
vaibhav@vaibhav:~$ echo '0 1000 1' > /proc/2506/
gid_map
-bash: echo: write error: Operation not permitted

现在如果我检查1号航站楼

$ id
uid=0(root) gid=65534(nogroup) groups=65534(nogroup)

我知道我们只能写入 uid_map 和 gid_map 文件一次，但它在第一次写入时失败。

我想知道为什么写入 gid_map 失败。我在用着Linux Mint 20.3

答案1

自 Linux 3.19 起，当非特权用户尝试映射用户组时，添加了一个特定的限制：他们必须放弃更改补充组的权利。这通常是为了防止用户消除其本身来自一个组，该组充当具有所有权如someuser:denygroup和 mode的文件的拒绝过滤器u=rw,g=,o=r。

如果没有这个限制，用户可以直接调用setgroups(2)并清空其补充组列表。

这记录在user_namespaces(7)：

写“拒绝”/proc/[pid]/setgroups写入之前的文件 将在用户命名空间中/proc/[pid]/gid_map永久禁用并且setgroups(2)/proc/[pid]/gid_map允许在父用户命名空间中不具有 CAP_SETGID 功能的情况下进行写入。

所以对于OP的情况：

echo deny > /proc/2506/setgroups

将放弃对补充组的控制并允许完成：

echo '0 1000 1' > /proc/2506/gid_map

笔记：

  • 用户只能将自己的 uid/gid 映射到另一个，并且唯一有趣的值是其本身或根。为了获得更多可能性，可以使用 setuid-root 帮助程序newuidmap和newgidmap使用每个用户分配的范围/etc/subuid和/etc/subgid。这是用户非特权容器实际工作方式的一部分：使用特权助手。

  • 作为安全说明，当特权命令在继续之前newgidmap写入allow时/proc/[pid]/setgroups，只需让该命令可用就可以逃脱拒绝组无论如何，“监狱”。此命令在用户可以运行自己的非特权容器的环境中普遍存在。

相关内容