Pergunta
Adicionar CAP_SYS_ADMIN
ainda é a única maneira de fazer o fuse funcionar dentro de um contêiner sem raiz (com sobreposição nativa ou fuse-overlayfs
/outros métodos)?
Exemplos
Podman em podman
Este exemplo de 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
funciona para mim sem problemas. Mas me faz supor que está usando fusermount
dentro do contêiner ou que é possível usá-lo, o que não funciona quando se usa a mesma configuração.
Além do mais, parece não montar nada:
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)
Parece que omitir /dev/fuse
também funciona (testado com sobreposição nativa):
podman run --user podman --security-opt label=disable -ti quay.io/podman/stable podman run -ti docker.io/busybox echo hello
Ligações
Apenas adicionando bindfs
à imagem
FROM quay.io/podman/stable
RUN dnf -y install bindfs
E executando um contêiner
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
Estou assumindo que o comportamento será o mesmo para outras montagens de fusíveis, como sshfs
. Isso pode ser um problema de permissão dentro do contêiner ou o host está negando?
Ideias
precisa de privilégio
Essa resposta implica que para usar o fuse, você precisa ter privilégios.
Setuid é mencionado, mas não tenho certeza de como isso é significado. Dentro do continer:
ls -l $(which fusermount3)
-rwsr-xr-x. 1 root root 40800 Jul 17 00:00 /usr/bin/fusermount3
sobreposição sem raiz
Também tentei remover a linha mount_program
de storage.conf
e executar podman system reset
, como descrito aqui . Mas não tenho certeza se isso é apenas sobre overlay ou também fuse. Se eu não adicionar /dev/fuse
, o dispositivo não estará presente no continer:
Outra desvantagem do fuse-overlayfs é que ele requer acesso a /dev/fuse. Quando as pessoas tentam executar o Podman e o Buildah em um contêiner confinado, retiramos os privilégios CAP_SYS_ADMIN, mesmo quando executados como root. Isso nos força a usar um namespace de usuário para que possamos montar volumes. Para fazer isso funcionar, os usuários precisam adicionar /dev/fuse ao contêiner. Assim que tivermos overlay nativo para o modo sem root (sem CAP_SYS_ADMIN), /dev/fuse não será mais necessário.
Versões
Host: Fedora 41
Podman: 5.3.1
Parece que encontrei uma solução (fiz o exemplo o mais curto possível):
Fonte: https://zameermanji.com/blog/2022/8/5/using-fuse-without-root-on-linux/#alternative-approach
Era um problema de capacidade, porque, durante o teste, funcionava com qualquer um dos sinalizadores:
--privileged
(desabilita a maioria dos mecanismos de segurança)--cap-add=all
(desabilita apenas a queda de letras maiúsculas)Parece que montagens de fuse sem privilégios são possíveis quando executadas a partir de novos userns e mountns. Não tenho certeza se podman poderia preparar os namespaces - ele pode manipular userns, mas não encontrei nada sobre mountns. Mas executar
unshare -pfr --user --mount --kill-child /bin/bash
no contêiner parece funcionar bem.A bandeira
--security-opt label=disable
também não parece ser necessária.