Linux 네임 스페이스에 대해 읽은 후에는 다른 많은 기능 중에서 chroot의 대안이라는 인상을 받았습니다. 예를 들어,에서 이 문서 :
네임 스페이스의 다른 용도로는 단일 디렉토리 계층의 일부에 대한 프로세스의 […] chroot () 스타일 격리가 있습니다.
그러나 예를 들어 다음 명령으로 마운트 네임 스페이스를 복제해도 여전히 전체 원래 루트 트리가 표시됩니다.
unshare --mount -- /bin/bash
원래 네임 스페이스와 공유되지 않는 새 네임 스페이스에서 추가 마운트를 수행 할 수 있으므로 격리를 제공하지만 여전히 동일한 루트입니다. 예를 들어 /etc두 네임 스페이스에서 여전히 동일합니다. 여전히 chroot루트를 변경 해야 합니까, 아니면 대안이 있습니까?
이 질문에 답 이 될 것으로 기대 했지만 대답은 chroot다시 사용 합니다.
편집 # 1
언급 된 댓글이 삭제되었습니다 pivot_root. 이것은 실제로의 일부이므로 linux/fs/namespace.c네임 스페이스 구현의 일부입니다. 이것은 즉에서만 루트 디렉토리를 변경 제안 unshare하고 mount불가능하지만 네임 스페이스는 자신의 제공 – 더 똑똑한 -의 버전 chroot. 여전히 chroot소스 코드를 읽은 후에도 (예를 들어 보안 또는 더 나은 격리라는 의미 에서 ) 근본적으로 다른이 접근법의 주요 아이디어를 얻지 못합니다 .
편집 # 2
이것은 이 질문과 중복되지 않습니다 . 답변에서 모든 명령을 실행 한 후 별도의 /tmp/tmp.vyM9IwnKuY (또는 유사)가 있지만 루트 디렉토리는 여전히 동일합니다!
답변
를 설정하기 전에 마운트 네임 스페이스를 입력하면 chroot예를 들어 for 등의 추가 마운트로 호스트 네임 스페이스를 복잡하게 만들 수 있습니다 /proc. chroot마운트 네임 스페이스 내부를 훌륭하고 간단한 핵으로 사용할 수 있습니다 .
나는 이해하는 데 이점이 있다고 생각 pivot_root하지만 약간의 학습 곡선이 있습니다. man 8 pivot_root(셸 명령에 대한 사용법 예제가 있지만) 설명서에 모든 내용이 설명되어 있지는 않습니다 . man 2 pivot_root(시스템 호출의 경우) 동일한 작업을 수행하면 더 명확하고 예제 C 프로그램이 포함됩니다.
pivot_root를 사용하는 방법
마운트 네임 스페이스를 입력 한 직후에도 mount --make-rslave /이와 동등하거나 필요 합니다. 그렇지 않으면 모든 마운트 변경 사항이를 포함하여 원래 네임 스페이스의 마운트로 전파됩니다 pivot_root. 당신은 그것을 원하지 않습니다 :).
unshare --mount명령 을 사용한 경우 mount --make-rprivate기본적 으로 적용 되도록 문서화되어 있습니다 . AFAICS 이것은 잘못된 기본값이며 프로덕션 코드에서는 원하지 않습니다. 예를 들어이 시점 eject에서 호스트 네임 스페이스의 마운트 된 DVD 또는 USB에서 작동 하지 않습니다 . DVD 또는 USB는 개인용 마운트 트리 내부에 마운트 된 상태로 유지되며 커널은 DVD를 꺼내지 못하게합니다.
이 작업을 마치면 사용할 /proc디렉토리 등을 마운트 할 수 있습니다 . 같은 방식으로 chroot.
사용할 때와는 달리 chroot, pivot_root새로운 루트 파일 시스템이 마운트 지점입니다해야합니다. 아직 마운트되지 않은 경우 바인드 마운트를 적용하여이를 만족시킬 수 있습니다 mount --rbind new_root new_root.
/ 옵션 과 함께 pivot_root-를 사용 umount하고 이전 루트 파일 시스템을 사용하십시오 . ( 필요하지 않으므로 시간이 더 걸릴 수 있습니다. ).-lMNT_DETACHumount -R
기술적으로, 사용은 pivot_root일반적으로 사용 을 포함해야합니다 chroot. “또는-“가 아닙니다.
당으로 man 2 pivot_root, 그것은 단지 마운트 네임 스페이스의 루트를 교환으로 정의합니다. 프로세스 루트가 가리키는 실제 디렉토리를 변경하도록 정의되지 않았습니다. 또는 현재 작업 디렉토리 ( /proc/self/cwd). 것을 어떻게 않습니다 그렇게, 그러나 이것은 핸들의 커널 스레드에 대한 해킹입니다. 맨 페이지는 향후 변경 될 수 있다고 말합니다.
일반적으로이 순서를 원합니다.
chdir(new_root); // cd new_root
pivot_root(".", put_old); // pivot_root . put_old
chroot("."); // chroot .
chroot이 순서에서 의 주장은 또 다른 미묘한 세부 사항 입니다. 요점은 pivot_root마운트 네임 스페이스를 재배 열하는 것이지만 커널 코드는 프로세스 별 루트를 보면 루트 파일 시스템을 찾는 것처럼 보입니다 chroot.
pivot_root를 사용하는 이유
원칙적 pivot_root으로 보안 및 격리 에 사용 하는 것이 좋습니다 . 기능 기반 보안 이론에 대해 생각하고 싶습니다 . 필요한 특정 리소스 목록을 전달하면 프로세스가 다른 리소스에 액세스 할 수 없습니다. 이 경우 마운트 네임 스페이스로 전달 된 파일 시스템에 대해 이야기합니다. 이 아이디어는 일반적으로 Linux “네임 스페이스”기능에 적용되지만 잘 표현하지는 못합니다.
chroot프로세스 루트 만 설정하지만 프로세스는 여전히 전체 마운트 네임 스페이스를 참조합니다. 프로세스가 수행 할 권한을 보유한 경우 chroot파일 시스템 네임 스페이스를 백업 할 수 있습니다. 에 설명 된대로 man 2 chroot, “슈퍼 유저에 의한 ‘는 chroot 감옥’에서 탈출 할 수 …”.
실행을 취소하는 또 다른 생각을 유발하는 방법 chroot은 nsenter --mount=/proc/self/ns/mnt입니다. 이것은 아마도이 원칙에 대한 더 강력한 주장 일 것이다. nsenter/ setns()는 마운트 네임 스페이스의 루트에서 프로세스 루트를 반드시 다시로드합니다 . 비록 두 개가 서로 다른 물리적 디렉토리를 참조 할 때 작동한다는 사실은 커널 버그로 간주 될 수 있습니다. (기술 노트 : 루트에서 서로의 위에 여러 파일 시스템이 마운트 될 수 있습니다. setns()가장 최근에 마운트 된 파일 시스템을 사용하십시오).
이것은 마운트 네임 스페이스와 “PID 네임 스페이스”를 결합 할 때의 이점을 보여줍니다. PID 네임 스페이스 내에 있으면 제한되지 않은 프로세스의 마운트 네임 스페이스를 입력 할 수 없습니다. 또한 확인되지 않은 프로세스의 루트 ( /proc/$PID/root) 를 입력하지 못하게합니다 . 물론 PID 네임 스페이스는 외부의 프로세스를 종료하지 못하게합니다 :-).