- 다른 설치 네임스페이스의 파일과 디렉터리에 계속 액세스할 수 있습니다.만약에당신은 그들의 참고 자료를 가지고 있습니다. 그러나 현재는 실행 중인 네임스페이스가 아닌 경우 네임스페이스를 마운트하는 마운트를 작동(또는 나열)할 수 없습니다.
- 분리된 마운트(
umount -l)는 마운트 네임스페이스가 없는 것으로 간주되므로 조작(또는 하위 마운트 나열)이 허용되지 않습니다.
예를 들어 보안상의 이유로 네임스페이스 API에 포인트 1(또는 포인트 2)의 제한 사항이 중요합니까? 기존 소프트웨어가 이에 의존합니까?
그렇지 않다면 Linux 코드에서 포인트 2(및 포인트 1)의 제한 사항을 제거하는 것이 어려울까요? 즉, 그렇게 하는 데 주요 장애물은 무엇입니까?
동기: 별도의 마운트 트리를 만들 수 있다면 chroot그 안으로 들어갈 수 있고 마운트 네임스페이스는 기본적으로 중복된다고 생각합니다. 하지만 다른 유형의 Linux 네임스페이스에는 여전히 어느 정도 편의성/일관성을 제공합니다.
답변1
활용할 수 있는 별도의 마운트 트리를 구축할 수 있다면
chroot마운트 네임스페이스는 기본적으로 중복된다고 생각합니다. 하지만 다른 유형의 Linux 네임스페이스에는 여전히 어느 정도 편의성/일관성을 제공합니다.
내 생각엔 (적어도) 중요한 점을 놓치고 있는 것 같다.
네임스페이스의 특징 중 하나는 사용자 네임스페이스와 연결되어 있다는 것입니다. 사용자 네임스페이스는 CAP_SYS_ADMIN 및 CAP_NET_RAW와 같은 "수퍼유저" 기능을 격리합니다. 예를 들어, CAP_NET_RAW는 사용자에게 속한 네트워크 네임스페이스가 소유한 경우 네트워크 장치의 원시 네트워크 패킷에 대한 액세스를 허용할 수 있습니다.
CAP_SYS_ADMIN을 사용하면 사용자에게 속한 마운트 네임스페이스를 작동할 수 있습니다. 현재 제한사항은 꼭 필요한 것보다 더 제한적일 수 있지만 몇 가지 제한사항이 필요합니다. 사용자 네임스페이스가 CAP_MOUNT를 격리할 수 있도록 마운트 트리를 네임스페이스에 바인딩하는 것이 필요합니다.
네임스페이스 마운트에 대한 대안을 구현하는 것은 사용자 네임스페이스에서는 작동하지 않기 때문에 별 의미가 없는 것 같습니다.