애플리케이션에서 특정 설치 네임스페이스로 일시적으로 "전환"하여 내용을 확인한 /proc다음 애플리케이션이 시작된 설치 네임스페이스로 다시 전환한 다음 다른 설치 네임스페이스로 전환해야 합니다.
애플리케이션은 "root" 마운트 네임스페이스를 사용하여 루트 사용자로 시작됩니다(여기에는 두 가지 다른 루트 개념이 있습니다!).
후드 아래에서 setns()앞뒤로 전환할 수 있습니다. 가장 중요한 것은 Zalando를 사용한다는 것입니다nsenter Python 라이브러리. 이 라이브러리를 사용하면 /proc/self/ns/[nstype]나중에 다시 전환하는 데 사용되는 fd를 먼저 열어 특정 네임스페이스에 "입력"할 수 있습니다. 그런 다음 파일 시스템의 네임스페이스 경로를 가져와서 fd를 열고 setns(fd, 0). 그런 다음 첫 번째 fd를 사용하여 원래 네임스페이스에 다시 연결하고 setns()다시 사용합니다. 이는 네트워크 네임스페이스에 적합합니다.
하지만 점프 마운트 네임스페이스의 경우 떠나기 전에 동일한 마운트 네임스페이스를 다시 입력하려고 하면 실패합니다. 여기서 점프한다는 것은 내 애플리케이션이 마운트 네임스페이스로 들어가서 일부 작업을 수행하고 원래 마운트 네임스페이스로 돌아가서 다시 마운트 네임스페이스로 전환한 다음 다시 전환하는 것을 의미합니다.
아무튼 문제는 컨테이너 안의 컨테이너에 있는 것 같습니다.
마운트 네임스페이스 전환에 제한 사항이 있나요? 어쩌면 사용자 네임스페이스와 관련이 있을까요? 이것마운트 네임스페이스 매뉴얼 페이지사용자 네임스페이스와 관련하여 언급했지만 컨테이너의 마운트 네임스페이스를 생성할 때 활성화된 다양한 사용자 네임스페이스가 해당 컨테이너 마운트 로드 네임스페이스에 대한 루트 권한을 사용하여 루트 사용자 네임스페이스로 또는 루트 사용자 네임스페이스에서 전환하는 내 애플리케이션에 어떤 영향을 미치는지 이해하지 못합니다. 이러한 마운트 네임스페이스로 전환하면 내 애플리케이션이 권한을 잃어 나중에 실패하게 됩니까?
그러니 거인에게 경의를 표하세요.마운트 네임스페이스 호핑은 유해한 것으로 간주됩니까?
답변1
아마도 매뉴얼 페이지 끝 부분에 이 작은 인쇄물이 있을 것입니다.설정(2)내 딜레마의 핵심은 다음과 같습니다.
마운트 네임스페이스를 변경하려면 호출자가 자체 사용자 네임스페이스에 CAP_SYS_CHROOT 및 CAP_SYS_ADMIN 기능과 대상 마운트 네임스페이스에 CAP_SYS_ADMIN 기능을 모두 갖고 있어야 합니다.
다른 컨테이너 내부에 있는 컨테이너의 마운트 네임스페이스에 들어간 후 내 애플리케이션/프로세스에서 일부 CAP가 손실되어 마운트 네임스페이스 내부에 잠긴 것 같습니다. s5ill은 여전히 궁금합니다. 루트 설치 네임스페이스와 다시 연결하려고 할 때 오류/예외가 없습니다...
전환의 일반적인 사용 사례는 대상 네임스페이스로 전환한 다음 사라지지만 다시는 전환하지 않는 것입니다. 네임스페이스가 마운트되면 다시 돌아올 생명선이 없는 것처럼 보입니다.