실험 1
네임스페이스 외부에서 cat /proc/self/mountinfo
다음을 제공합니다 .
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
그런 다음 네임스페이스 내에서 get new shell을 실행했지만 새로 생성된 mount 네임스페이스 내에서는 umount 를 unshare -mU --map-root-user --propagation private /usr/bin/zsh
수행할 수 없었고 아직 마운트되지 않았다는 메시지만 표시되었습니다. 새로 생성된 마운트 네임스페이스를 확인할 수 있지만 프라이빗 마운트를 제공합니다./tmp/IMJUSTTMP
umount
cat /proc/self/mountinfo
290 263 0:32 / /tmp rw,nosuid,nodev - tmpfs tmpfs rw
302 290 0:37 / /tmp/IMJUSTTMP rw,relatime - tmpfs tmpfs rw,size=102400k
umount: /tmp/IMJUSTTMP: not mounted.
그렇다면 /tmp/IMJUSTTMP
네임스페이스 내에서 제거하려고 할 때 이런 일이 발생하는 이유는 무엇입니까?
저는 5.0.9-arch1-1-ARCH를 사용하고 있습니다 kernel.unprivileged_userns_clone = 1
.
실험 2
그 후 unshare -mU --map-root-user --propagation private /usr/bin/zsh
, overlayfs를 생성하려는 시도도 실패했습니다.
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
모든 것이 예상대로 성공하고 아래의 모든 것이 permission denied
네임스페이스에 들어갑니다.
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
내 대략적인 추측
이 두 가지 문제점을 발견했는데,사용자 네임스페이스 내에서 이미 마운트된 파일 시스템을 다시 마운트할 수 없는 이유는 무엇입니까?그리고사용자 네임스페이스 내에서 마운트 "/"를 바인딩할 수 없는 이유는 무엇입니까?상속 /tmp/IMJUSTTMP
하고 /tmp
마운트하기 때문에 새로 생성된 마운트 네임스페이스의 소유 사용자 네임스페이스에서 전체 기능을 얻더라도 마운트 해제할 수 없는 것 같습니다.
질문
이 두 실험에서 정확히 무슨 일이 일어났는지 설명할 수 있는 사람이 있나요? 마운트 네임스페이스 내에서 마운트 및 마운트 해제의 자세한 커널 동작을 언급하는 문서가 있습니까? "슈퍼 블록 소유자"란 무엇입니까?이 커널은 커밋합니다.그리고사용자 네임스페이스 내에서 마운트 "/"를 바인딩할 수 없는 이유는 무엇입니까??
답변1
예:-). 여기에는 세 가지 다른 점이 있습니다.
umount: /tmp/IMJUSTTMP: not mounted
실험 1: umount /tmp/IMJUSTTMP
네임스페이스를 입력하려고 하면 오류가 발생하는 이유는 무엇입니까?
[...]
마운트 네임스페이스 제한
네임스페이스 마운트와 관련하여 다음 사항에 유의하세요.
각 마운트 네임스페이스에는 소유자 사용자 네임스페이스가 있습니다. 위에서 언급한 것처럼 새로운 마운트 네임스페이스가 생성되면 해당 마운트 목록은 다른 마운트 네임스페이스의 마운트 목록 복사본으로 초기화됩니다. 새 네임스페이스와 마운트 목록이 복사된 네임스페이스가 서로 다른 사용자 네임스페이스에 속하는 경우 새 마운트 네임스페이스는 권한이 낮은 것으로 간주됩니다.
권한이 낮은 마운트 네임스페이스가 생성되면 공유 마운트가 슬레이브 마운트로 축소됩니다. 이렇게 하면 권한이 낮은 설치 네임스페이스에서 수행된 매핑이 권한이 더 높은 설치 네임스페이스로 전파되지 않습니다.
권한이 더 높은 마운트 네임스페이스의 마운트는 단일 단위로 함께 잠겨 있으며 권한이 낮은 마운트 네임스페이스에서 분리될 수 없습니다. (unshare(2) CLONE_NEWNS 작업은 원래 마운트 네임스페이스의 모든 마운트를 단일 단위로 전파하고, 마운트 네임스페이스 간에 전파되는 재귀 마운트는 단일 단위로 전파합니다.
[...]
실험 2: overlayfs 생성 시도도 실패했습니다.
권한 없는 파일 시스템 마운트, 2018년판 [LWN.net]
일반 사용자가 안전하게 장착 작업을 수행할 수 있도록 노력하는 것은 새로운 것이 아닙니다. 저수온망패치 세트로 덮으세요2008년으로 돌아갑니다. 이 작업은 병합되지 않았지만 권한 없는 마운트를 허용하려는 노력이었습니다.집어 들었다2015년에 Eric Biederman(및 다른 사람들, 특히 Seth Forshee)은 사용자 네임스페이스가 파일 시스템 마운트를 수행하도록 허용하는 것을 진지하게 고려하기 시작했습니다. 이것예비 작업 2016년에 4.8 커널로 병합되었으나, 해당 문제에 대한 완전한 해결책은 아닌 것으로 알려져 있으므로,대부분의 파일 시스템은 여전히 초기 네임스페이스에 대한 권한이 있는 사용자만 마운트할 수 있습니다..
2008년 LWN 기사에는 "사용자 네임스페이스 내에서 사용하기에 안전함"이 확인된 파일 시스템이 FS_USERNS_MOUNT
.로 표시되어 쉽게 검색할 수 있다고 명시되어 있습니다.허용되는 파일 시스템.
이 표시를 주목하세요커널 버전 5.11의 OverlayFS에 추가됨. 따라서 이제 권한이 있는 사용자 및 마운트 네임스페이스 내에서 하나를 마운트할 수 있습니다.
이 커널 커밋에 언급된 "슈퍼블록 소유자"는 무엇이며 "왜 사용자 네임스페이스 내에서 마운트 "/"를 바인딩할 수 없습니까?"라는 질문이 있습니까?
링크한 커널 커밋의 소스 코드에 따르면 각 슈퍼블록은 특정 사용자 네임스페이스가 소유한 것으로 간주됩니다. 소유자는 원래 슈퍼블록을 생성한 사용자 네임스페이스입니다.