问为什么非根用户不能取消共享pid命名空间？

EN

这确实是不允许的，因为它是一个特权操作：unshare(2)告诉：

CLONE_NEWPID (自Linux3.8起) CLONE_NEWPID requires 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时，请注意末尾。

安装一个反映新pid命名空间的/proc的新实例，以实际查看新的pids，而不是从父命名空间中看到的pids，也应该这样做：

$ 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命令的最新版本来完成此操作)。如果此进程不是特权(命令newuidmap和newgidmap是setuid，因此可以在父命名空间中设置为该用户保留的任何映射)，那么对于有用的映射(通常是根或用户本身)，很少有选择。

其他shell (仍在父命名空间中)：

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