Как процесс может содержать возможность в другом пространстве имен?

Вообще-то ответ был прямо у меня под носом, в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).

Таким образом, на самом деле существует троичное отношение Процесс × Пространство имен × Возможности. Я так понимаю:

1. Очевидно, что процесс имеет те возможности в пользовательском пространстве имен, членом которого он является, которые находятся в его действующем наборе возможностей. Здесь нет ничего удивительного.

2. Наличие возможности удерживает иерархию пространств имен пользователей. Тоже ничего удивительного.

3. Если процесс P является членом пользовательского пространства имен U, и у U есть дочернее пользовательское пространство имен U', а eUID процесса P является UID U', то 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]

Это пространство имен пользователей с идентификатором 4026532574 имеет родительское пространство имен пользователей 4026531837 и UID 1000, если смотреть снаружи (см. ниже ). Таким образом, он должен соответствовать критериям, упомянутым выше. Но все же я не вижу расширенных возможностей для процесса сна:

# grep Cap /proc/4101/status
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000

Возможно, мне придется смонтировать новый /proc, но я не знаю, как это сделать, не затеняя процесс sleep...

примечание

Из различных обрывков кода и справочных страниц я собрал довольно случайный -специальный nsrel для исследования иерархий пространств имен. В приведенном выше примере при запуске в начальном пространстве имен он дает

$ nsrel 4111 user
ID          TYPE      PARENT      USERNS      UID
4026532574  User      4026531837  4026531837  1000
4026531837  User      <oos>       <oos>       0

, который показывает, что процесс 4111 находится в пользовательском пространстве имен 4026532574, которое имеет родительское пространство имен 4026531837 и принадлежит UID 1000.