UTS 네임스페이스 격리가 작동하지 않는 이유는 무엇입니까?

UTS 네임스페이스 격리가 작동하지 않는 이유는 무엇입니까?

1. 별도의 하위 UTS 네임스페이스에서 셸 프로세스를 시작합니다.

sudo unshare -f --mount-proc -u /bin/bash

2.이 과정에서 호스트 이름을 변경하세요

hostnamectl set-hostname newhostname

3. 다양한 쉘의 변경 사항 모니터링

$ hostname
newhostname

예상되는 결과

프로세스는 상위 네임스페이스에 이전 호스트 이름을 유지합니다.

결과는

새 UTS 네임스페이스에서 호스트 이름을 변경하면 상위 네임스페이스의 호스트 이름도 변경됩니다.


왜 이런 일이 발생합니까? 저는 Ubuntu 20.04, 커널 버전 5.10.23-xanmod1( uname -r)을 사용하고 있습니다.

답변1

hostnamectl다음은체계sethostname(2)환경이며 시스템 호출을 수행하지 않습니다 . 그것은 물었다체계소켓을 통해 이를 수행하십시오 /run/dbus/system_bus_socket. ~처럼체계네임스페이스를 변경하지 않고 초기 네임스페이스에서 이 작업을 수행하며 이전 UTS 네임스페이스의 이름(런타임 시 초기 이름)을 제공된 새 이름으로 변경하고 새 UTS 네임스페이스의 이름은 변경되지 않은 상태로 유지합니다(OP의 선언과 유사). 반대): 이전 호스트 이름. 파일이 /etc/hostname변경되는 등의 다른 부작용도 있습니다 .

이는 를 사용하여 확인할 수 있습니다 strace. 그 안에는 아무것도 없지만 sethostname(2)눈에 띄는 시스템 관련 요소가 있습니다.

newfstatat(AT_FDCWD, "/run/systemd/system/", {st_mode=S_IFDIR|0755, st_size=40, ...}, AT_SYMLINK_NOFOLLOW) = 0

위의 호출이 성공하지 못하게 하면( unshare -f -u -m /bin/basha를 사용하고 모두 재정의하여) 다음과 같은 결과를 얻을 수 있습니다./runmount -t tmpfs tmpfs /run

System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

대화 상자는 나중에 아래와 같이 열린 소켓으로 완료됩니다.

connect(3, {sa_family=AF_UNIX, sun_path="/run/dbus/system_bus_socket"}, 30) = 0

hostname이 환경에서는 읽기를 위해 낮은 수준의 "레거시" 명령을 사용해야 합니다.또는호스트 이름을 변경하세요. 시스템 호출을 직접 호출합니다 sethostname(2). 새 UTS 네임스페이스의 이름을 변경하고 이전(초기) UTS 네임스페이스는 변경되지 않은 채로 둡니다.

hostname newhostname

새로운 UTS 네임스페이스에 영향을 미치 려면 hostnamectl(LXC를 사용하여 시작된 전체 컨테이너와 마찬가지로) 하나 이상의 unshare명령, 즉 완전히 새로운 UTS 인스턴스가 필요합니다.체계생태계는 새로운 환경에 존재해야 하며, 이를 위해서는 여러 추가 네임스페이스와 많은 추가 상용구를 가져오거나 공유 취소해야 할 수 있습니다.

관련 정보