☰

Dentro de um namespace de usuário, por que não tenho permissão para remontar um sistema de arquivos que montei?

tag-icon • tag-icon linux mount namespace
Dentro de um namespace de usuário, por que não tenho permissão para remontar um sistema de arquivos que montei?

https://github.com/systemd/systemd/issues/9914#issuecomment-416387637

$ uname -r
4.17.18-200.fc28.x86_64

$ unshare -U -r -m
# mkdir TMP
# mount -t tmpfs tmpfs TMP/
# mount -o remount,ro TMP/
mount: ./TMP: permission denied.

# grep TMP /proc/self/mountinfo
834 831 0:74 / /home/alan/TMP rw,relatime - tmpfs tmpfs rw,seclabel,uid=1001,gid=1001
# strace -f mount -o remount TMP/
...
mount("tmpfs", "/home/alan/TMP", 0x557c3cec9600, MS_REMOUNT|MS_RELATIME, "seclabel,uid=1001,gid=1001") = -1 EPERM (Operation not permitted)
...

A remontagem de ligação funciona bem.

 # strace -f mount -o remount,bind,ro TMP/
 mount("tmpfs", "/home/alan/TMP", 0x5615b7ebc130, MS_RDONLY|MS_REMOUNT|MS_BIND|MS_RELATIME, "seclabel,uid=1001,gid=1001") = 0

Responder1

Não foi implementado. Mas está na próxima versão!

v4.18 inclui o seguinte commit. Isso não fornece nenhum motivo mais específico para não ter suporte anteriormente.

https://github.com/torvalds/linux/commit/bc6155d13260

fs: Permitir que o proprietário do superbloco acesse do_remount_sb()

As remontagens em nível de superbloco estão atualmente restritas ao CAP_SYS_ADMIN global, assim como o caminho para alterar a montagem raiz para somente leitura em umount. Afrouxe ambas as verificações de permissão para permitir também CAP_SYS_ADMIN em qualquer namespace que seja privilegiado para os usuários que originalmente montaram o sistema de arquivos.

informação relacionada