主页 / unix / 问题 / 789293
Accepted
rudib
Asked: 2025-01-09 21:08:25 +0800 CST

无根、无特权 podman 中的 FUSE

  • 772

问题

添加CAP_SYS_ADMIN仍然是使 fuse 在无根容器内工作的唯一方法吗（使用本机覆盖或fuse-overlayfs/其他方法）？

示例

Podman 中的 Podman

此示例来自https://www.redhat.com/en/blog/podman-inside-container

podman run --user podman --security-opt label=disable --device /dev/fuse -ti quay.io/podman/stable podman run -ti docker.io/busybox echo hello

对我来说没有问题。但它让我假设它是fusermount在容器内部使用，或者可以使用它，而使用相同的设置时则不起作用。

更重要的是，它似乎没有安装任何东西：

podman run --user podman --security-opt label=disable --device /dev/fuse -ti quay.io/podman/stable
# running commands in container
cat /proc/mounts > /home/podman/before
podman run -d docker.io/busybox sleep 100
cat /proc/mounts > /home/podman/during
diff /home/podman/before /home/podman/during
# (no difference)

似乎省略/dev/fuse也有效（使用本机覆盖进行测试）：

podman run --user podman --security-opt label=disable -ti quay.io/podman/stable podman run -ti docker.io/busybox echo hello

绑定文件系统

只需添加bindfs到图像中

FROM quay.io/podman/stable

RUN dnf -y install bindfs

运行一个容器

podman run --user podman --security-opt label=disable --device /dev/fuse -ti built_image_from_above:latest
# inside the container
cd ~ && mkdir test1 test2
bindfs --no-allow-other test1 test2
fusermount: mount failed: Operation not permitted

我假设其他保险丝座的行为也相同，例如sshfs。这可能是容器内的权限问题，还是主机拒绝了它？

想法

需要特权

这个答案暗示要使用 fuse，您需要拥有特权。

提到了 Setuid，但我不确定它是什么意思。在 continer 中：

ls -l $(which fusermount3)
-rwsr-xr-x. 1 root root 40800 Jul 17 00:00 /usr/bin/fusermount3

无根覆盖

我也尝试mount_program过从 中删除行storage.conf并运行podman system reset，如此处所述。但我不确定这是否仅与覆盖有关，还是也与保险丝有关。如果我不添加/dev/fuse，则设备不会出现在 continer 中：

fuse-overlayfs 的另一个缺点是它需要访问 /dev/fuse。当人们尝试在受限容器内运行 Podman 和 Buildah 时，我们会取消 CAP_SYS_ADMIN 权限，即使以 root 身份运行也是如此。这迫使我们使用用户命名空间，以便我们可以挂载卷。为了实现这一点，用户必须将 /dev/fuse 添加到容器中。一旦我们有了无根模式（无 CAP_SYS_ADMIN）的原生覆盖，就不再需要 /dev/fuse。

版本

Host: Fedora 41
Podman: 5.3.1
fuse

1 个回答

  1. Best Answer

    看起来我找到了一个解决方案（使示例尽可能简短）：

    podman run --device /dev/fuse -ti fedora:41
# inside the container
cd ~ && mkdir test1 test2
unshare -pfr --user --mount --kill-child /bin/bash
# now inside the process within the new ns
bindfs --no-allow-other test1 test2
# mounts ok

    来源：https://zameermanji.com/blog/2022/8/5/using-fuse-without-root-on-linux/#alternative-approach

    这是一个功能问题，因为在测试时，它可以与以下任一标志一起使用：

    • --privileged（禁用大多数安全机制）
    • --cap-add=all（仅禁用掉首字母）

    似乎从新的 userns 和 mountns 执行非特权 fuse 挂载是可能的。我不确定 podman 是否可以准备命名空间 - 它可以操纵 userns，但我没有找到有关 mountns 的任何信息。但unshare -pfr --user --mount --kill-child /bin/bash在容器中运行似乎工作正常。

    该标志--security-opt label=disable似乎也没有必要。

    • 0

相关问题