了解Docker中的用户文件所有权：如何避免更改链接卷的权限

Question

考虑以下琐碎的Dockerfile：

FROM debian:testing
RUN  adduser --disabled-password --gecos '' docker
RUN  adduser --disabled-password --gecos '' bob

在没有其他任何工作目录中。构建docker映像：

docker build -t test .

然后在容器上运行bash脚本，将工作目录链接到bob的主目录上的新子目录中：

docker run --rm -it -v $(pwd):/home/bob/subdir test

谁拥有subdir容器中的物品？在容器上，运行：

cd /home/bob/subdir
ls -l

我们看到的广告：

-rw-rw-r-- 1 docker docker 120 Oct 22 03:47 Dockerfile

圣烟！docker拥有内容！回到容器外部的主机上，我们看到原始用户仍然拥有Dockerfile。让我们尝试修复bobhome目录的所有权。在容器上，运行：

chown -R bob:bob /home/bob
ls -l

我们看到：

-rw-rw-r-- 1 bob bob 120 Oct 22 03:47 Dockerfile

可是等等！在容器外面，我们现在运行ls -l

-rw-rw-r-- 1 1001 1001 120 Oct 21 20:47 Dockerfile

我们不再拥有我们自己的文件。可怕的消息！

如果在上面的示例中仅添加一个用户，那么一切将会更加顺利。出于某种原因，Docker似乎会将其遇到的 第一个
非根用户拥有任何主目录（即使该用户是在较早的映像上声明的）。同样， 第一个 用户是与我的家庭用户相同的所有权权限的用户。

问题1 正确吗？有人可以指出我的相关文档吗，我只是基于上述实验进行猜测。

问题2
：也许这仅仅是因为它们在内核上具有相同的数值，并且如果我在我的家庭用户不是id的系统上进行了测试，1000那么在每种情况下权限都会改变吗？

问题3 ：当然，真正的问题是，“我该怎么办？”
如果以给定主机上的bob身份登录bob，则他应该能够以该身份运行该容器，bob并且在其主机帐户下没有更改文件权限。就目前而言，他实际上需要以用户docker身份运行容器，以避免更改其帐户。

我听到你在问 为什么我仍然有这么奇怪的Dockerfile？
。我有时也想知道。我正在为一个Webapp（RStudio服务器）编写一个容器，该容器允许不同的用户登录，该容器仅将linux计算机中的用户名和凭据用作有效的用户名。这给我带来了想要创建多个用户的不寻常动机。我可以通过仅在运行时创建用户来解决此问题，一切都很好。但是，我使用的基础映像添加了一个docker用户，因此可以交互使用而无需以root用户身份运行（按照最佳做法）。由于该用户成为第
一个 用户，这破坏了一切
__用户并最终拥有所有内容，因此尝试在其他用户失败时登录（该应用无法启动，因为它缺少写入权限）。chown首先运行启动脚本可以解决此问题，但要以链接卷更改权限为代价（显然，如果我们要链接卷，则只会出现问题）。

Answer 1

那是对的吗？有人可以指出我的相关文档吗，我只是基于上述实验进行猜测。

也许这仅仅是因为它们在内核上具有相同的数值，如果我在我的家庭用户的ID不是1000的系统上进行测试，那么在每种情况下权限都会改变吗？

阅读info coreutils 'chown invocation'，可能会使您更好地了解文件权限/所有权的工作方式。

但是，基本上，计算机上的每个文件都有一组附加的位，以定义其权限和所有权。当您chown创建文件时，只需设置这些位。

当chown使用用户名或组名将文件发送给特定的用户/组时，chown将查找/etc/passwd用户名和/etc/group组，以尝试将名称映射到ID。如果这些文件中不存在用户名/组名，chown则将失败。

root@dc3070f25a13:/test# touch test
root@dc3070f25a13:/test# ll
total 8
drwxr-xr-x  2 root root 4096 Oct 22 18:15 ./
drwxr-xr-x 22 root root 4096 Oct 22 18:15 ../
-rw-r--r--  1 root root    0 Oct 22 18:15 test
root@dc3070f25a13:/test# chown test:test test
chown: invalid user: 'test:test'

但是，chown无论您的计算机上是否存在使用这些ID的用户/组，都可以使用ID来实现所需的文件（当然，在某个正整数上限内）。

root@dc3070f25a13:/test# chown 5000:5000 test
root@dc3070f25a13:/test# ll
total 8
drwxr-xr-x  2 root root 4096 Oct 22 18:15 ./
drwxr-xr-x 22 root root 4096 Oct 22 18:15 ../
-rw-r--r--  1 5000 5000    0 Oct 22 18:15 test

UID和GID位是在文件本身上设置的，因此，当您将这些文件安装在Docker容器内时，该文件具有与主机上相同的所有者/组UID，但现在已映射到/etc/passwd容器中，即除非它由root（UID
0）拥有，否则可能会是其他用户。

真正的问题当然是“我该怎么办？”
如果bob在给定的主机上以bob身份登录，则他应该能够以bob身份运行容器，并且在其主机帐户下没有更改文件权限。就目前而言，他实际上需要以用户docker的身份运行该容器，以避免更改其帐户。

看起来，在当前设置下，如果您要与安装的用户目录以同一用户身份进行交互，则需要确保/etc/passwd主机上的UID>用户名与容器中的UID>用户名匹配/etc/passwd在主机上登录。

您可以使用创建具有特定用户ID的用户useradd -u xxxx。Buuuut，这似乎是一个混乱的解决方案…

您可能需要提出一种不装载主机用户主目录的解决方案。