Linux 컨테이너 (LXC 컨테이너)를 "권한 없음"이라고하는 것은 무엇을 의미합니까?
Linux 컨테이너 (LXC 컨테이너)를 "권한 없음"이라고하는 것은 무엇을 의미합니까?
답변:
권한이없는 LXC 컨테이너는 사용자 네임 스페이스 ( userns )를 사용하는 컨테이너 입니다. 네임 스페이스에 호스트 된 UID의 범위를 매핑 할 수있는 커널 기능 즉 내부 UID 0을 가진 사용자가 다시 존재할 수있는.
권한이없는 LXC 컨테이너에 대한 초기 인식과는 달리, 권한이없는 호스트 사용자가 컨테이너를 소유해야한다는 의미는 아닙니다. 그것은 단지 하나의 가능성입니다.
관련은 :
usermod [-v|-w|--add-sub-uids|--add-sub-gids])lxc.id_map = ...)에 매핑됩니다.따라서 root호스트에서 컨테이너 프로세스의 효과적인 UID가 매핑에 의해 정의 된 범위 내에있게되므로 권한이없는 컨테이너를 소유 할 수도 있습니다.
그러나 root먼저 하위 ID를 정의해야합니다. 를 통해 생성 달리 사용자는 adduser, root기본적으로 정의 된 하위 ID의 범위가되지 않습니다.
또한 제공하는 전체 범위를 마음대로 사용할 수 있으므로 다음 구성 줄이있는 3 개의 컨테이너가있을 수 있습니다 (UID 매핑 만 표시됨).
lxc.id_map = u 0 100000 100000lxc.id_map = u 0 200000 100000lxc.id_map = u 0 300000 100000root100000에서 400000 사이의 하위 UID 를 소유 한다고 가정합니다. 내가 찾은 모든 문서는 컨테이너 당 65536 하위 ID를 사용하고 일부는 100000을 사용하여 사람이 읽기 쉽도록 만듭니다.
즉, 각 컨테이너에 동일한 범위를 할당 할 필요는 없습니다.
40 억 (~ 2^32) 이상의 하위 ID를 사용할 수 있으므로 하위 범위를 호스트 사용자에게 처리 할 때 관대 할 수 있습니다.
다시 문지르세요. 권한이없는 LXC 게스트는 호스트의 권한이없는 사용자가 실행할 필요가 없습니다.
다음과 같은 하위 UID / GID 매핑으로 컨테이너를 구성하십시오.
lxc.id_map = u 0 100000 100000
lxc.id_map = g 0 100000 100000
root호스트 의 사용자 가 주어진 하위 ID 범위를 소유하고 있으면 게스트를 더 잘 제한 할 수 있습니다.
그러나 이러한 시나리오에는 하나의 중요한 추가 이점이 있습니다 (예, 작동하는지 확인했습니다). 시스템 시작시 컨테이너를 자동 시작할 수 있습니다.
일반적으로 LXC에 대한 정보를 웹에서 검색 할 때는 권한이없는 LXC 게스트를 자동 시작할 수 없다는 메시지가 나타납니다. 그러나 컨테이너의 시스템 전체 저장소에없는 컨테이너 (일반적으로와 같은 /var/lib/lxc) 에 대해서는 기본적으로 만 적용됩니다 . 그것들이 (일반적으로 루트에 의해 생성되고 루트에 의해 시작된다는 것을 의미), 완전히 다른 이야기입니다.
lxc.start.auto = 1
컨테이너 구성에 넣으면 작업을 아주 잘 수행합니다.
나는 이것으로 조금 어려움을 겪었으므로 여기에 섹션을 추가하고 있습니다.
lxc.include일반적으로 이름 을 따르는 구성 스 니펫 외에도 /usr/share/lxc/config/$distro.common.conf(여기서 $distro배포자의 이름 임) /usr/share/lxc/config/$distro.userns.conf시스템에 있는지 확인 하고이를 포함시켜야합니다. 예 :
lxc.include = /usr/share/lxc/config/ubuntu.common.conf
lxc.include = /usr/share/lxc/config/ubuntu.userns.conf
또한 하위 ID 매핑을 추가하십시오.
lxc.id_map = u 0 100000 65535
lxc.id_map = g 0 100000 65535
이는 호스트 UID 100000이 LXC 게스트의 사용자 네임 스페이스 root 내에 있음을 의미합니다 .
이제 권한이 올바른지 확인하십시오. 손님의 이름이 환경 변수에 저장 $lxcguest되면 다음을 실행하십시오.
# Directory for the container
chown root:root $(lxc-config lxc.lxcpath)/$lxcguest
chmod ug=rwX,o=rX $(lxc-config lxc.lxcpath)/$lxcguest
# Container config
chown root:root $(lxc-config lxc.lxcpath)/$lxcguest/config
chmod u=rw,go=r $(lxc-config lxc.lxcpath)/$lxcguest/config
# Container rootfs
chown 100000:100000 $(lxc-config lxc.lxcpath)/$lxcguest/rootfs
chmod u=rwX,go=rX $(lxc-config lxc.lxcpath)/$lxcguest/rootfs
이렇게하면 첫 번째 시도에서 권한 관련 오류가 발생한 후 컨테이너를 실행할 수 있습니다.
chroot하면 도움이 될 수 있지만 LXC는 다양한 네임 스페이스 (UTS, 마운트 등 ...)를 결합하여 전체 시스템을 컨테이너화합니다.
unshare이미 다양한 네임 스페이스에 대해 훌륭하게 수행 /proc하고 있으며 단일 cli-switch 로 별도의 개인 마운트를 얻을 수도 있습니다 . 귀하의 경우 하나의 응용 프로그램 입니다 init당신이 chroot인 initramfs당신은 초 플랫의 전체 컨테이너를 얻을.
그 솔루션 나를 위해 벌금을했다 0xC0000022L에 후속하려면 내가 쓴 increase-uid-gid.pl LXC 컨테이너 내에서 파일이 제대로 매핑되도록 필요한 소유권이 필요한 변경 자동화 해주는 펄 스크립트를.
이 설정이 없으면이 제안 된 설정을 사용하여 LXC 컨테이너 rootfs 내의 파일이 기본 호스트의 0 / root에 속하는 파일이 LXC 컨테이너 자체의 65534 / nobody에 매핑됩니다. LXC 컨테이너 내에서 0 / 루트로 매핑 되려면 호스트에서 100000에 속해야합니다.
이것은 여기 https://yeupou.wordpress.com/2017/06/23/setting-up-lxc-containers-with-mapped-giduid/에 설명 되어 있으며 스크립트는 gitlab https://gitlab.com 에서 직접 얻을 수 있습니다 /yeupou/stalag13/blob/master/usr/local/bin/increase-uid-gid.pl
lxc이런 종류의 물건에는 필요하지 않습니다.util-linux도구를 사용하여 모든 종류의 네임 스페이스 컨테이너를 만들 수 있습니다unshare.util-linux도구를 사용하여 해당 컨테이너에 들어갈 수 있습니다nsenter. 후자의 도구를 사용하면 실행중인 프로세스를 이미 생성 된 컨테이너에 추가 할 수 있습니다. 네임 스페이스 지원은 커널 내에서 구현됩니다.