☰

无法在非共享命名空间中使用用户/组 ID

tag-icon • tag-icon linux namespace
无法在非共享命名空间中使用用户/组 ID

当在与我的“常规”系统分离的安装和用户命名空间中安装 tmpfs 时，我的期望是可以使用任何用户/组 ID。

不需要映射 ID，因为 tmpfs 仅存在于该挂载命名空间中（不过，我设置了 /etc/sub{g,u}id）。

但发生的事情是这样的：

me   $ mkdir tmp
me   $ unshare -Urm
root $ mount -t tmpfs none tmp
root $ cd tmp
root $ touch asdf
root $ chown 3:3 asdf
chown: changing ownership of 'asdf': Invalid argument

我无法找出原因。有人可以对此进行一些说明吗？

对于复制粘贴测试unshare -Urm：

mkdir tmp
mount -t tmpfs none tmp
cd tmp
touch asdf
chown 3:3 asdf

答案1

对于给定的用户命名空间，命名空间内未映射给定 UID 或 GID 的任何进程（这甚至会影响本来运行的实际初始 root 用户unshare -Urnm），具体取决于系统调用，在以下情况下将收到 EPERM 或 EINVAL 错误：尝试做一些以某种方式影响此类 UID 的事情（例如：对于进程或文件）。这在中进行了解释user_namespace(7)，但解释相当复杂。

尝试读取此类 UID/GID 的值，如果没有导致 EINVAL，则会检索溢出的 UID/GID，通常为无人和非组，详细信息请参见未映射的用户和组 ID从user_namespace(7)手册页。

涉及多个自己的 UID 的唯一方法是使用特权助手。有一对这样常见的帮助程序，它们甚至是旨在以普通用户身份运行的工具的依赖项，例如podman.命令newuidmap和newgidmap验证用户凭据/etc/subuid和/etc/subgid。这些文件中的条目通常在创建用户帐户时添加，但可以进行修改以满足进一步的需要。

如果用户可以单方面更改用户命名空间以成为 root 并影响父（例如：主机）用户命名空间，则该用户将拥有 root 用户的权限。事实并非如此。使用帮助程序的预期用途是为此用户保留一系列 UID-GID（在 0-4294967294 的子范围内，而不仅仅是 0-65534）。为了问责制，不同用户之间的映射应该是不同的（但这不是必需的）。

相关内容