☰

사용자 네임스페이스 내에서 마운트한 파일 시스템을 다시 마운트할 수 없는 이유는 무엇입니까?

tag-icon • tag-icon linux mount namespace
사용자 네임스페이스 내에서 마운트한 파일 시스템을 다시 마운트할 수 없는 이유는 무엇입니까?

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)
...

바인드 재마운트가 정상적으로 작동합니다.

 # 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

답변1

구현되지 않았습니다. 그래도 다음 버전에 있습니다!

v4.18에는 다음 커밋이 포함되어 있습니다. 이전에 지원되지 않았던 더 구체적인 이유는 제공되지 않습니다.

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

fs: 슈퍼블록 소유자가 do_remount_sb()에 액세스하도록 허용합니다.

슈퍼블록 수준 재마운트는 현재 전역 CAP_SYS_ADMIN으로 제한되며, 마운트 해제 시 루트 마운트를 읽기 전용으로 변경하는 경로도 마찬가지입니다. 원래 파일 시스템을 마운트한 사용자에 대한 권한이 있는 모든 네임스페이스에서 CAP_SYS_ADMIN을 허용하려면 이러한 권한 검사를 모두 느슨하게 하십시오.

관련 정보