Podman Rootless 技巧：利用 `--Group-Add Keep-Groups` 解决卷组权限难题

AI 生成 + 人工编辑

对于使用 Podman Rootless 模式的用户来说，在容器中访问宿主机上通过组权限管理的目录，是一个棘手的问题。本文将介绍一个实用技巧，通过在启动容器时使用 --group-add keep-groups 参数，优雅地解决这一权限难题。

场景设定

示例场景：

• 运行环境: 你正在以非 root 用户（例如 nite，UID 为 1000）的身份运行 Podman Rootless 容器。
• 宿主机用户组: 你的用户 nite 属于 git 组。
• 共享目录: 宿主机上有一个名为 repos 的目录，其权限设置为允许 git 组的成员进行读写访问。
• 容器需求: 你希望在 Podman 容器中也能顺利访问和操作 repos 目录。

当你尝试将 repos 目录作为卷挂载到容器中时，常常会遇到权限问题。一个典型的现象是，在容器内部查看该目录的所有权时，会显示为 nobody:nobody 且访问时得到 Permission denied 错误。

Rootless 容器的用户命名空间

要理解这个问题的根源，我们需要了解 Podman Rootless 模式的核心机制：用户命名空间（User Namespaces）。

在 Rootless 模式下，Podman 会创建一个用户命名空间，将宿主机上运行容器的普通用户（例如 nite，UID 1000）映射为容器内的 root 用户（UID 0）。 同样，宿主机上的用户组 GID 也会被映射。这种映射机制是 Rootless 容器安全性的基石，它确保了即使用户在容器内拥有 root 权限，在宿主机上依然只是一个普通用户。

然而，当涉及到宿主机上通过附加组（supplementary group）授予权限的目录时，问题就出现了。默认情况下，启动容器时，容器内的进程不会继承宿主机用户的附加组关系。 这就是为什么即便宿主机上的 nite 用户因为属于 git 组而可以访问 repos 目录，容器内的进程却无法访问的原因。

解决方案：--group-add keep-groups

为了解决这个问题，Podman 提供了一个强大的参数：--group-add keep-groups。

这个参数的作用是，在启动容器时，让容器内的进程保持（keep）其父进程（即在宿主机上运行 podman run 命令的用户）的附加组。

具体来说，当使用此参数时，Podman 会指示底层的 OCI 运行时（如 crun）在创建容器进程时不调用 setgroups 系统调用。 setgroups 通常会重置进程的组信息为容器内定义的组，从而丢弃从父进程继承的组。通过跳过这一步，容器内的进程就“继承”了宿主机用户的组关系。

因此，你的启动命令会是这样：

podman run -it --rm \
  -v /path/to/your/repos:/repos \
  --group-add keep-groups \
  your-image:tag

“神秘”的 nobody:nobody

一个有趣且可能令人困惑的现象是，即使使用了 --group-add keep-groups 参数后，你在容器内执行 ls -l 查看挂载的 repos 目录，其所有者和所属组可能仍然显示为 nobody:nobody。

这是因为宿主机上 repos 目录的 GID（git 组的 GID）并未被映射到容器内的用户命名空间中。 因此，容器无法将这个 GID 解析为一个已知的组名，只能将其显示为 nobody 或一个溢出的 GID。

然而，这并不影响实际的访问权限。由于容器内的进程已经通过 keep-groups 继承了宿主机 git 组的成员资格，因此内核会正确地判断该进程拥有访问此目录的权限。