네임스페이스와 함수 간의 상호 작용에 대해 생각하고 있습니다. 때때로 나는 user_namespaces
(7)에서 다음과 같은 표현을 우연히 발견합니다 .
Holding CAP_SYS_ADMIN within the user namespace that owns a
process's mount namespace allows that process to ...
나는 다음 사항을 이해합니다:
각각의 비사용자 네임스페이스 N은 사용자 네임스페이스 U에 속하며, 이는 당시 U에서 N을 생성한 프로세스에 의해 결정됩니다.
기능은 프로세스(보다 정확하게는 스레드) 또는 파일의 속성입니다. 이 논의를 위해서는 지금 당장의 과정을 생각해 보는 것만으로도 충분하다고 생각합니다.
각 네임스페이스 유형에 대해 각 프로세스는 해당 유형의 하나의 네임스페이스에 상주합니다.
계층을 형성하는 것은 PID 네임스페이스와 사용자 네임스페이스입니다. 문서의 표현에 대한 제가 이해한 바는 프로세스 P가 네임스페이스 B의 하위인 네임스페이스 A에 있더라도 여전히 P가 B에 있다고 말할 수 없다는 것입니다. P는 A에 있고 P는 A에 위치하기 때문입니다. 유형의 네임스페이스. 즉, 네임스페이스 부모 관계를 컬렉션 포함과 혼동해서는 안 됩니다.
이제 문구를
Holding a capability within the user namespace U that owns a
process's mount namespace M allows that process P to ...
프로세스 P에서 마운트 네임스페이스 M(/proc/P/ns/mnt)으로 이동하여 프로세스가 속한 사용자 네임스페이스 U를 찾은 다음( ioctl_ns
(2)) 프로세스에 U의 기능이 있는지 확인하라고 지시합니다. .
이것이 제가 이해하지 못하는 마지막 부분입니다. P가 반드시 U에 속할 필요는 없는데 어떻게 거기에서 능력을 가질 수 있습니까? 프로세스 × 사용자 네임스페이스 ↦ 함수 매핑이 있나요? 또한 U는 UID와 연결되어 있지만 기능은 사용자 ID의 속성이 아닙니다.
답변1
사실, 대답은 내 코 바로 아래에 있는 user_namespaces
(7)에서 이미 관련 부분을 뒤집은 것 같습니다. 아래에 인용하겠습니다.
1. A process has a capability inside a user namespace if it is a member
of that namespace and it has the capability in its effective capa‐
bility set. A process can gain capabilities in its effective capa‐
bility set in various ways. For example, it may execute a set-user-
ID program or an executable with associated file capabilities. In
addition, a process may gain capabilities via the effect of
clone(2), unshare(2), or setns(2), as already described.
2. If a process has a capability in a user namespace, then it has that
capability in all child (and further removed descendant) namespaces
as well.
3. When a user namespace is created, the kernel records the effective
user ID of the creating process as being the "owner" of the name‐
space. A process that resides in the parent of the user namespace
and whose effective user ID matches the owner of the namespace has
all capabilities in the namespace. By virtue of the previous rule,
this means that the process has all capabilities in all further re‐
moved descendant user namespaces as well. The NS_GET_OWNER_UID
ioctl(2) operation can be used to discover the user ID of the owner
of the namespace; see ioctl_ns(2).
따라서 실제로 프로세스 × 네임스페이스 × 기능의 삼원 관계가 있습니다. 내 이해는 다음과 같습니다.
프로세스는 해당 유효 기능 세트 내에서 자신이 속한 사용자 네임스페이스에 이러한 기능을 분명히 갖고 있습니다. 여기서는 놀랄 일이 아닙니다.
사용자 네임스페이스 계층을 억제하는 기능이 있습니다. 놀랍지도 않습니다.
프로세스 P가 사용자 네임스페이스 U의 멤버이고 U가 하위 사용자 네임스페이스 U'를 갖고 P의 eUID가 U'의 UID인 경우 P는 U'의 모든 기능을 갖습니다.
아쉽게도 3번을 제가 제대로 이해했는지는 잘 모르겠지만, 다음 실험에서는 관찰에 실패했습니다.
$ id -u
1000
$ echo $$
4083
$ readlink /proc/4083/ns/user
user:[4026531837]
$ sleep 10001 &
[1] 4101
$ readlink /proc/4101/ns/user
user:[4026531837]
$ ps -p 4101 -o pid,euid,comm
PID EUID COMMAND
4101 1000 sleep
이제 sleep
사용자 네임스페이스 4026531837에 상주하며 eUID 1000을 갖습니다.
$ unshare -r
# echo $$
4111
# readlink /proc/4111/ns/user
user:[4026532574]
외부에서 보면 ID가 4026532574인 사용자 네임스페이스에는 상위 사용자 네임스페이스가 4026531837이고 UID가 1000입니다(아래 참조). 따라서 위의 기준을 충족해야 합니다. 그러나 여전히 절전 프로세스의 확장된 기능이 표시되지 않습니다.
# grep Cap /proc/4101/status
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
neww를 설치해야 할 수도 있지만 /proc
프로세스에 영향을 주지 않고 설치하는 방법을 모르겠습니다 sleep
...
사이드 노트
다양한 코드 조각과 매뉴얼 페이지에서 좀 특별한 것을 모아봤습니다.엔스라엘네임스페이스 계층 구조를 연구합니다. 위의 예에서는 초기 네임스페이스에서 실행될 때 다음을 생성합니다.
$ nsrel 4111 user
ID TYPE PARENT USERNS UID
4026532574 User 4026531837 4026531837 1000
4026531837 User <oos> <oos> 0
프로세스 4111은 사용자 네임스페이스 4026532574에 표시됩니다. 이 사용자 네임스페이스의 상위 네임스페이스는 4026531837이며 UID 1000에 속합니다.