Início / unix / Perguntas / 517317
Accepted
炸鱼薯条德里克
Asked: 2019-05-06 18:37:17 +0800 CST

Sobre como montar e desmontar montagens herdadas dentro de um namespace de montagem recém-criado

  • 772

Experimento 1

De fora do namespace, cat /proc/self/mountinfodá

291 34 0:37 / /tmp/IMJUSTTMP rw,relatime shared:152 - tmpfs tmpfs rw,size=102400k
34 23 0:32 / /tmp rw,nosuid,nodev shared:16 - tmpfs tmpfs rw

Então eu corro unshare -mU --map-root-user --propagation private /usr/bin/zshpara obter um novo shell dentro de um namespace, mas dentro do namespace mount recém-criado, não consigo umount /tmp/IMJUSTTMP, umountapenas me diga que não está montado. Embora eu possa verificar o namespace de montagem recém-criado por cat /proc/self/mountinfo, que fornece montagem privada

290 263 0:32 / /tmp rw,nosuid,nodev - tmpfs tmpfs rw
302 290 0:37 / /tmp/IMJUSTTMP rw,relatime - tmpfs tmpfs rw,size=102400k

Então, por que recebo umount: /tmp/IMJUSTTMP: not mounted.quando tento desmontar /tmp/IMJUSTTMPdentro do namespace?

Estou usando 5.0.9-arch1-1-ARCH, com kernel.unprivileged_userns_clone = 1.

Experimento 2

Depois unshare -mU --map-root-user --propagation private /usr/bin/zshde , tentar criar um overlayfs também falha.

mkdir -p /tmp/IMJUSTTMP/work
mkdir /tmp/IMJUSTTEST
mount -t tmpfs -o size=100m tmpfs /tmp/IMJUSTTMP
mount -t tmpfs -o size=200M tmpfs /tmp/IMJUSTTEST

Todos terão sucesso conforme o esperado, enquanto todos os itens a seguir entrariam permission deniedno namespace.

mount -t overlay -o "lowerdir=/home/xtricman,upperdir=/tmp/IMJUSTTMP/,workdir=/tmp/IMJUSTTMP/work" overlay /home/xtricman
mount -t overlay -o "lowerdir=/tmp/IMJUSTTEST,upperdir=/tmp/IMJUSTTMP,workdir=/tmp/IMJUSTTMP/work" overlay /mnt

Adivinhação minha

Encontrei essas duas perguntas: Dentro de um namespace de usuário, por que não tenho permissão para remontar um sistema de arquivos que montei? e Por que não posso ligar "/" dentro de um namespace de usuário? Parece que, como eu herdo o /tmp/IMJUSTTMPand /tmpmount, não posso desmontá-los, mesmo que tenha recursos completos no namespace de usuário proprietário do namespace mount recém-criado.

Pergunta

Alguém pode explicar o que exatamente está acontecendo dos dois experimentos? Existe algum documento mencionando o comportamento detalhado do kernel de montagem e desmontagem dentro de um namespace de montagem? Qual é o "proprietário do superbloco" conforme mencionado neste commit do kernel e Por que não posso ligar "/" dentro de um namespace de usuário? ?

linux-kernel mount

1 respostas

  1. Best Answer

    Sim :-). Há três pontos distintos aqui.

    Experimento 1: Por que recebo umount: /tmp/IMJUSTTMP: not mountedquando tento umount /tmp/IMJUSTTMPentrar no namespace?

    http://man7.org/linux/man-pages/man7/mount_namespaces.7.html

    Restrições em namespaces de montagem

    Observe os seguintes pontos em relação aos namespaces de montagem:

    • Um namespace de montagem tem um namespace de usuário proprietário. Um namespace de montagem cujo namespace de usuário proprietário é diferente do namespace de usuário proprietário de seu namespace de montagem pai é considerado um namespace de montagem menos privilegiado.

    • Ao criar um namespace de montagem menos privilegiado, as montagens compartilhadas são reduzidas a montagens escravas. (As montagens compartilhadas e escravas são discutidas abaixo.) Isso garante que os mapeamentos executados em namespaces de montagem menos privilegiados não sejam propagados para namespaces de montagem mais privilegiados.

    • As montagens que vêm como uma única unidade de montagens mais privilegiadas são travadas juntas e não podem ser separadas em um namespace de montagem menos privilegiado. (A operação unshare(2) CLONE_NEWNS traz todas as montagens do namespace de montagem original como uma única unidade, e montagens recursivas que se propagam entre namespaces de montagem se propagam como uma única unidade.)

    • As configurações dos sinalizadores mount(2) MS_RDONLY, MS_NOSUID, MS_NOEXEC e os sinalizadores "atime" (MS_NOATIME, MS_NODIRATIME, MS_RELATIME) ficam bloqueadas quando propagadas de um namespace de montagem mais privilegiado para um menos privilegiado, e não podem ser alteradas no namespace de montagem menos privilegiado.

    Experimento 2: Tentar criar uma sobreposição também falha

    As tentativas de tornar a operação de montagem segura para usuários comuns não são novidade; O LWN cobriu um patch definido em 2008. Esse trabalho nunca foi mesclado, mas o esforço para permitir montagens sem privilégios foi retomado em 2015, quando Eric Biederman (junto com outros, Seth Forshee em particular) levou a sério a permissão de namespaces de usuários para realizar montagens de sistemas de arquivos . O trabalho inicial foi mesclado em 2016 para o kernel 4.8, mas sabia-se que não era uma solução completa para o problema, portanto, a maioria dos sistemas de arquivos ainda pode ser montada apenas por usuários privilegiados no namespace inicial .

    Montagens de sistema de arquivos sem privilégios, edição de 2018 , LWN.net

    O artigo do LWN de 2008 diz que os sistemas de arquivos que foram verificados como "seguros para uso em namespaces de usuário" são sinalizados como FS_USERNS_MOUNT. Assim, podemos pesquisar facilmente quais sistemas de arquivos são permitidos .

    Observe que esse sinalizador foi adicionado ao OverlayFS com a versão 5.11 do kernel . Portanto, agora você pode montar um dentro de um usuário privilegiado e montar um namespace.

    Qual é o "proprietário do superbloco" conforme mencionado neste commit do kernel e a pergunta "Por que não posso vincular a montagem "/" dentro de um namespace de usuário?" ?

    O código-fonte no commit do kernel ao qual você se vincula, diz que cada superbloco é considerado de propriedade de um namespace de usuário específico. O proprietário é o namespace do usuário que originalmente criou o superbloco.

    • 2

relate perguntas