경로가 보이는 방식과 데이터의 위치를 나눕니다
새 mount namespace는 기존 마운트 목록을 복제해 시작합니다. 파일 내용 전체를 복사하지는 않습니다. 서로 다른 namespace가 같은 파일시스템의 같은 파일을 가리킨다면, 한쪽의 쓰기가 다른 쪽에서도 보일 수 있습니다. namespace가 다르다고 해서 데이터가 격리됐다고 판단하면 안 됩니다.
마운트 목록: 어느 파일시스템이 어느 경로에 붙어 있는가
실제 데이터: 두 경로가 같은 파일·계층을 가리키는가
접근 조건: 읽기 전용·권한·추가 마운트는 무엇인가
OverlayFS 계층과 공유 마운트는 다른 문제입니다
Docker의 고전적인 overlay2 구성은 읽기 전용 이미지 계층과 컨테이너의 쓰기 계층을 합칩니다. lower 파일을 수정할 때 copy-up이 일어나 새 upper 쪽에 변경을 남깁니다. 이 데이터 계층 구성은 mount namespace 자체의 기능이 아닙니다. 저장 드라이버·snapshotter에 따라 구성이 달라지므로 특정 호스트 디렉터리를 모든 설치의 보편 경로로 외우지 않습니다.
반대로 같은 호스트 파일을 writable bind mount로 연결하면 컨테이너에서 한 변경이 그 파일에 반영될 수 있습니다. 별도 namespace나 별도 이미지가 이 공유 경로를 자동으로 private copy로 바꾸지는 않습니다. 공유가 필요한 경로와 읽기 전용으로 제한할 경로를 따로 정합니다.
전파는 마운트별로 확인합니다
shared는 peer group 사이에 하위 mount·unmount 이벤트를 전달하고, slave는 master 쪽 이벤트를 한 방향으로 받습니다. private은 그 전파를 차단합니다. 한 namespace 안에서도 마운트마다 설정이 다를 수 있습니다. 파일 내용의 공유와 mount 이벤트의 전파를 같은 의미로 사용하지 않습니다.
util-linux unshare 명령은 2.27부터 새 mount namespace의 전파를 기본적으로 private으로 바꿉니다. --propagation unchanged로 이를 끌 수 있습니다. 이 명령의 기본 동작을 CLONE_NEWNS를 쓰는 모든 프로그램의 동작으로 일반화하지 않습니다.
루트 경로 변경은 별도 계약입니다
OCI Runtime Spec v1.2.1은 root.path와 추가 mounts를 별도 필드로 정의합니다. 이 설정 형식만으로 모든 런타임이 같은 시스템 호출을 사용한다고 결론 내릴 수는 없습니다. pivot_root는 호출자의 mount namespace에서 루트 마운트를 바꾸며, 같은 namespace에서 이전 루트를 가리키던 프로세스의 root·cwd에도 조건부로 영향을 줍니다. 모든 호스트 프로세스의 루트를 바꾸는 호출은 아닙니다.
chroot는 경로 해석의 루트를 바꾸지만 그 자체로 완전한 보안 경계가 아닙니다. 열린 파일 디스크립터, 작업 디렉터리, 권한과 다른 격리 수단을 함께 고려해야 합니다.
변경하기 전에 관측 대상을 고정합니다
다음은 현재 셸의 namespace와 마운트 정보를 읽는 예시입니다. pid를 다른 값으로 바꾸면 /proc 조회는 그 대상을 읽지만, 마지막 findmnt 명령은 여전히 자신이 실행되는 namespace를 읽습니다. 다른 대상은 권한과 도구 버전을 확인한 뒤 findmnt의 --task 옵션 등으로 명시해야 합니다. 여기서는 mount·unshare·pivot_root를 실행하거나 결과를 재현한 것으로 주장하지 않습니다.
pid=$$
readlink "/proc/${pid}/ns/mnt"
cat "/proc/${pid}/mountinfo"
findmnt -o TARGET,SOURCE,FSTYPE,PROPAGATION