取消共享用户名称空间,并使用newuidmap设置uid映射 [英] unshare user namespace and set uid mapping with newuidmap

查看:157
本文介绍了取消共享用户名称空间,并使用newuidmap设置uid映射的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试通过 unshare newuidmap 命令进行试验,以更好地了解用户名称空间.

I'm trying to gain a better understanding of user namespaces by experimenting with the unshare and newuidmap commands.

这些是我运行的命令:

[root@host ~]$ ls -l /usr/bin/newuidmap
-rwsr-xr-x 1 root root 32944 May 16 19:37 /usr/bin/newuidmap
[root@host ~]$  unshare -U bash namespace
[nobody@host ~]$ echo $$
7134
[nobody@host ~]$ newuidmap 7134 65534 5000 1
newuidmap: write to uid_map failed: Operation not permitted

/etc/subuid:

/etc/subuid:

nobody:5000:1
root:5000:1

知道为什么会失败吗?

然后我尝试在父命名空间的同一PID上运行 newuidmap 命令,它似乎可以正常工作:

I then tried to run the newuidmap command on the same PID from the parent namespace and it appeared to work:

[root@host ~]$ newuidmap 7134 65534 5000 1
[root@host ~]$ cat /proc/7134/uid_map 
 65534       5000          1

但是当我从新名称空间中运行一个进程时,它似乎仍然以root身份而不是UID 5000身份运行:

But when I run a process from within the new namespace it still seems to run as root instead of UID 5000:

[nobody@host ~]$ exec sleep 20

从另一个外壳:

[root@host ~]$ ps aux | grep 7134
root      7134  0.0  0.0   7292   708 pts/2    S+   02:07   0:00 sleep 20

我想念什么?

推荐答案

catanman

1)

[nobody@host ~]$ newuidmap 7134 65534 5000 1
newuidmap: write to uid_map failed: Operation not permitted

知道为什么会失败吗?

文档( http://man7.org/linux/man-pages/man7/user_namespaces.7.html )指出以下内容:

Documentation (http://man7.org/linux/man-pages/man7/user_namespaces.7.html) states the following:

由clone(2)使用CLONE_NEWUSER标志创建的子进程从新用户的一整套功能开始命名空间.< ...>请注意,对execve(2)的调用将导致进程的以通常的方式重新计算功能(请参阅功能(7)).

The child process created by clone(2) with the CLONE_NEWUSER flag starts out with a complete set of capabilities in the new user namespace. <...> Note that a call to execve(2) will cause a process's capabilities to be recalculated in the usual way (see capabilities(7)).

之所以发生这种情况,是因为unshare在将控制权交给用户之前会调用"exec bash",并且您释放了必要的功能,因此您无法在用户名称空间中更改uid_map/gid_map.

This happens because unshare calls 'exec bash' before returing the control to the user and you loose the necessary capabilities, thus you cannot change uid_map/gid_map from within user namespace.

不过,如果您编译某些应用程序(例如,您可以从user_namespaces(7)中的示例中进行一些小的修复),该应用程序会在'exec'之前更新uid_map/gid_map,则更新将成功.

Still, if you compile some application (e.g. you can make a small fix in an example from user_namespaces(7)) which updates uid_map/gid_map before 'exec', the update will succeed.

2)

但是当我从新名称空间中运行一个进程时,它似乎仍然以root身份而不是UID 5000的身份运行:

But when I run a process from within the new namespace it still seems to run as root instead of UID 5000:

我想念什么?

  • 该映射不会更改用户.映射将子名称空间中的ID链接到其父名称空间中的ID,而不是相反的方式.
  • 您可以从子名称空间中调用 setuid(2) seteuid(2),以将凭据更改为来自同一用户名称空间的其他凭据.当然,它们应该映射到父命名空间中的值,否则geteuid()函数将失败.
    • The mapping does not change the user. The mapping links ids in a child namespace to ids in its parent namespace, not the opposite way.
    • You can call setuid(2) or seteuid(2) from within a child namespace to change the credentials to some other credentials from the same user namespace. They of course should be mapped onto the values in the parent namespace, otherwise geteuid() function will fail.
    • 这里有两个例子:

      示例1.假设我们创建了一个子用户名称空间.

      Example 1. Suppose we have created a child user namespace.

      arksnote linux-namespaces   # unshare -U bash
      nobody@arksnote ~  $ id
      uid=65534(nobody) gid=65534(nobody) группы=65534(nobody)
      nobody@arksnote ~  $ echo $$
      18526
      

      现在让我们在子命名空间中将父命名空间的根与某些ID(在这种情况下为0)链接起来:

      Now let's link root from parent namespace with some id (0 in this case) in a child namespace:

      arksnote linux-namespaces   # newuidmap 18526 0 0 1
      arksnote linux-namespaces   # cat /proc/18526/uid_map
               0          0          1
      

      以下是子名称空间的发生情况:

      Here's what happens to the child namespace:

      nobody@arksnote ~  $ id
      uid=0(root) gid=65534(nobody) группы=65534(nobody)
      

      您可以尝试其他一些映射,例如 newuidmap 18526 1 0 1 ,并看到它被应用于子用户名称空间,而不是父用户名称空间.

      You can try some other mappings, like newuidmap 18526 1 0 1 and see that it is applied to the child user namespace, not the parent one.

      示例2 :现在我们没有为 root 设置映射:

      Example 2: Now we does not set a mapping for root:

      arksnote linux-namespaces   # newuidmap 18868 0  1000 1
      arksnote linux-namespaces   # cat /proc/18868/uid_map
               0       1000          1
      

      在这种情况下,子用户名称空间的用户 root 未知:

      In this case the user root is left unknown for the child user namespace:

      nobody@arksnote ~  $ id
      uid=65534(nobody) gid=65534(nobody) группы=65534(nobody)
      

      您对 [root @ host〜] $ newuidmap 7134 65534 5000 1 所做的工作是将父命名空间中的userid 5000与子命名空间中的uid 65534关联,但是该过程仍按 root .之所以显示为65534,是因为此值用于任何未知的id:

      What you have done with [root@host ~]$ newuidmap 7134 65534 5000 1 was association of userid 5000 in a parent namespace with uid 65534 in a child namespace, but the process still runs as root. It is shown as 65534 only because this value is used for any unknown id:

      函数getuid(),getgid()从/proc/sys/kernel/overflowgid 返回没有映射的uid/gids的值.该值对应一个没有任何系统权限的特殊用户: nobody ,如您在上面的输出中的uid/gid中所见.

      Functions getuid(), getgid() returns the value from /proc/sys/kernel/overflowgid for uids/gids which does not have a mapping. The value corresponds to a special user without any system rights:nobody, as you can see in uid/gid in the output above.

      请参阅user_namespaces(7)中的未映射的用户ID和组ID .

      See Unmapped user and group IDs in user_namespaces(7).

      这篇关于取消共享用户名称空间,并使用newuidmap设置uid映射的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆