Docker userns拥有的文件-重新映射用户最终由容器内的任何人拥有

Question

我正在研究Docker用户名称空间的重新映射：https://docs.docker.com/engine/security/userns-remap/

我已经通过修改/etc/docker/daemon.json实现了Docker用户命名空间的重新映射。当前内容如下所示：

{
  "userns-remap": "default"
}

我已经重新启动了Docker守护进程。默认dockremap用户是按照文档承诺的那样创建的：

user@host:~$ id dockremap
uid=125(dockremap) gid=134(dockremap) groups=134(dockremap)

在/etc/subuid中也有一个条目

dockremap:165536:65536

现在，我有一个包含共享文件的文件夹，我希望将其绑定挂载到容器中以使其可供读取。在主机操作系统上，该文件具有以下所有者和权限设置：

-rwxrwx--- 1 dockremap dockremap 0 april 8 19:19 shared_file.txt

该文件不应该是完全可写的。我的实际意图是在主机操作系统和容器之间安全地共享一个文件，其中包含一些秘密信息。

父目录是完全可写的，如果它有什么不同的话：

drwxrwxrwx 3 dockremap dockremap 4,0K april 8 19:20 .

我将其绑定挂载到一个阿尔卑斯山容器中，如下所示：

docker run --rm -it -w /work -v $(pwd)/shared_file.txt:/work/shared_file.txt remaptest ls -lah

我现在期望该文件由容器内UID为0的root所有，因此可以读取。相反，它归nobody所有，不能由root读取

-rwxrwx--- 1 nobody nobody 0 Apr 8 16:19 shared_file.txt

容器内的nobody具有以下ids：

/work # id nobody
uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)

我是否对用户名称空间重新映射和绑定挂载文件系统权限如何协同工作有错误的期望，或者这里有什么问题？我已经在两台不同的PC上进行了测试。其中一个运行Ubuntu，另一个运行Mint。

我还使用Ubuntu-based容器而不是Alpine-based容器进行了测试，但结果基本相同。当然，我可以修改用于构建映像的Dockerfile，但我的印象是，我在上面这样做的方式应该可以工作。

我想使用的实际Dockerfile来自Docker Hub，我不想弄乱它是如何设置的。

Answer 1

首先我要说的是，在我自己的非常有限的经验中，我发现用户名称空间映射是一个特别难以理解的主题，特别是在使用docker时。我个人觉得，这几乎是故意的，有错误的期望。但它仍然是一个强大的工具。

发生了什么？

在您的例子中，我会尝试将$(pwd)作为/work (而不仅仅是文件)挂载到容器中，并运行touch /work/test.txt。在您主机上，当您运行ls -lan $(pwd)时，您将看到该文件是由具有uid 165536的用户创建的。这是在您的主机/etc/subuid文件中声明的，但我同意这不一定是您所期望的。

可以做什么？

为了解决这个问题，我在/etc/subuid中更改或预先添加了映射。例如，您可以在dockremap:165536:65536之前添加一行，声明为dockremap:125:1。因为您主机上的dockremap的uid是125，而您只想映射这个uid，所以下面这行代码应该可以解决这个问题。

现在，如果您使用新文件再次执行touch测试，您将看到您的文件在主机上归125 (又称dockremap)所有，在容器中归0 (又称root)所有。

进一步阅读

我可以推荐这篇文章：https://www.jujens.eu/posts/en/2017/Jul/02/docker-userns-remap/