루트가 아닌 사용자가 pid 네임스페이스 공유를 해제할 수 없는 이유는 무엇입니까?

루트가 아닌 사용자가 pid 네임스페이스 공유를 해제할 수 없는 이유는 무엇입니까?

unshare -pf bash실패했으며 작업이 허용되지 않습니다.효과적인뿌리. proc을 마운트하지 않으면 ns를 마운트할 필요가 없습니다. pid ns 생성을 허용하지 않는 특별한 이유가 있나요?

답변1

이는 권한 있는 작업이므로 실제로 허용되지 않습니다.unshare(2)말하다:

CLONE_NEWPID(리눅스 3.8부터 시작)

[...]

사용하려면 능력이 CLONE_NEWPID필요함CAP_SYS_ADMIN. 자세한 내용은 다음을 참조하세요.pid_네임스페이스(7).

먼저 공유를 취소하면 됩니다.사용자 네임스페이스(이것은 권한 있는 작업이 아닙니다.) 그럼 다음과 같이댓글에 언급된, 그리고 기록된사용자 네임스페이스(7), 사용자 네임스페이스 공유를 해제하면 CAP_SYS_ADMIN최소한 다음 execve() 전에 해당 내용을 가져오는 데 충분하므로 여기에서 루트 사용자에 대한 매핑을 수행할 필요조차 없습니다. 이제 이 새로운 사용자 네임스페이스에서 프로세스는 새로운 pid 네임스페이스를 공유 해제할 수 있습니다.

pid_namespaces(7)에 명시된 대로 "이 플래그로 unshare(2)를 호출한 후 프로세스에 의해 생성된 첫 번째 하위 프로세스 CLONE_NEWPID"만이 실제로 새 pid 네임스페이스에 있고 "pid 1을 갖습니다". 따라서 포크 옵션은 기술적으로 필요하지 않지만 이것이 없으면 그다지 유용하지 않습니다. 왜냐하면 첫 번째 하위 프로세스만 실제로 새 pid 네임스페이스를 입력/시작하기 때문입니다(그리고 bash사용되지 않은 프로세스 와 마찬가지로 bash --norc포크되어 다음 중 하나를 실행할 기회를 잃게 됩니다). 나중에 스스로 선택)

$ unshare -U --map-user=$(id -u) --map-group=$(id -g) -f -p
$ echo $$
1

unshare이를 위해서는 관련 옵션을 갖춘 충분히 새로운 버전이 필요합니다. 이러한 옵션이 없는 이전 버전을 사용 하는 경우 unshare끝에 있는 참고 사항을 참조하세요.

/proc상위 네임스페이스의 pid 대신 새 pid를 실제로 보기 위해 새 pid 네임스페이스를 반영하는 새 인스턴스를 마운트하는 것도 수행해야 할 작업입니다.

$ ls -l /proc/$$/exe
ls: cannot read symbolic link '/proc/1/exe': Permission denied
lrwxrwxrwx 1 nobody nogroup 0 Sep 16 16:13 /proc/1/exe

이를 위해서는 새 네임스페이스에 마운트 권한이 필요하므로 사용자 네임스페이스도 이 새 마운트 네임스페이스에서 새 마운트를 수행할 수 있는 권한을 얻을 수 있도록 마운트 네임스페이스도 먼저 공유 해제해야 합니다. (최종 포크 및 실행 이전에) 공유되지 않은 프로세스가 여전히 CAP_SYS_ADMIN최종적으로 유용한 작업을 수행할 수 있기 때문에 여전히 루트일 필요는 없습니다 .

$ unshare -U --map-user=$(id -u) --map-group=$(id -g) -m --mount-proc -f -p 
$ echo $$
1
$ ls -l /proc/$$/exe
lrwxrwxrwx 1 user user 0 Oct  8 21:49 /proc/1/exe -> /usr/bin/bash

추가 참고 사항: 공유 해제는 루트가 아니라 동일한 사용자에게 매핑됩니다. unshare명령이 누락된 이전 버전을 사용하는 경우 --map-user다음과 같이 수행할 수 있습니다.

user@host$ echo $$; id -u; id -g; exec unshare -U -f -p
670034
1000
1000
nobody@host$ echo $$; id -u; id -g
1
65534
65534

그런 다음 새 사용자 네임스페이스에 대한 사용자 맵을 작성하려면 다른 프로세스의 일반적인 도움이 필요합니다(또는 최신 버전의 명령이 unshare이 작업을 먼저 수행할 수도 있음). 이 프로세스에 상위 네임스페이스(명령 newuidmapnewgidmapsetuid 루트에 대한 권한이 없으므로 원하는 경우 이 사용자에 대해 예약된 모든 매핑을 설정할 수 있음)에는 옵션이 거의 없습니다.효과가있다매핑(일반적으로 루트 또는 사용자 자체).

기타 쉘(여전히 상위 네임스페이스에 있음):

user@host$ pstree -p 670034
unshare(670034)───bash(670638)
user@host$ echo '1000 1000 1' > /proc/670034/uid_map
user@host$ echo deny > /proc/670034/setgroups
user@host$ echo '1000 1000 1' > /proc/670034/gid_map

다시 첫 번째 쉘:

nobody@host$ exec bash #for cosmetic effect
user@host$ echo $$; id -u; id -g
1
1000
1000

관련 정보