了解 docker 中的用户文件所有权:如何避免更改链接卷的权限 [英] Understanding user file ownership in docker: how to avoid changing permissions of linked volumes

问题描述

考虑以下简单的 Dockerfile:

Consider the following trivial Dockerfile:

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

在一个没有其他东西的工作目录中.构建 docker 镜像:

in a working directory with nothing else. Build the docker image:

docker build -t test .

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

and then run a bash script on the container, linking the working directory into a new subdir on bob's home directory:

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

谁拥有容器上 subdir 的内容?在容器上，运行:

Who owns the contents of subdir on the container? On the container, run:

cd /home/bob/subdir
ls -l

我们看到的广告:

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

天啊！docker 拥有内容！回到容器外的主机上，我们看到我们的原始用户仍然拥有 Dockerfile.让我们尝试修复 bob 主目录的所有权.在容器上，运行:

Holy smokes! docker owns the contents! Back on the host machine outside the container, we see that our original user still owns the Dockerfile. Let's try and fix the ownership of bob's home directory. On the container, run:

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

我们看到:

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

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

But wait! outside the container, we now run ls -l

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

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

we no longer own our own file. Terrible news!

如果我们在上面的例子中只添加了一个用户，一切都会更顺利.出于某种原因，Docker 似乎正在创建由它遇到的第一个 非 root 用户拥有的任何主目录(即使该用户是在较早的映像中声明的).同样，这个第一个用户是与我的家庭用户具有相同所有权权限的用户.

If we had only added one user in the above example, everything would have gone more smoothly. For some reason, Docker seems to be making any home directory owned by the first non-root user it encounters (even if that user is declared on an earlier image). Likewise, this first user is the one that corresponds to the same ownership permissions as my home user.

问题 1 对吗?有人可以指出我对此的文档，我只是根据上述实验进行推测.

Question 1 Is that correct? Can someone point me to documentation of this, I'm just conjecturing based on the above experiment.

问题 2:也许这只是因为它们在内核上具有相同的数值，并且如果我在我的家庭用户不是 id 1000 那么在每种情况下权限都会改变吗?

Question 2: Perhaps this is just because they both have the same numerical value on the kernel, and if I tested on a system where my home user was not id 1000 then permissions would get changed in every case?

问题 3:当然，真正的问题是我该怎么办?"如果 bob 在给定的主机上以 bob 的身份登录，他应该能够以 bob 的身份运行容器并且不会改变文件权限在他的主机帐户下.就目前而言，他实际上需要以用户 docker 运行容器，以避免他的帐户被更改.

Question 3: The real question is, of course, 'what do I do about this?' If bob is logged in as bob on the given host machine, he should be able to run the container as bob and not have file permissions altered under his host account. As it stands, he actually needs to run the container as user docker to avoid having his account altered.

我听到你在问为什么我有这么奇怪的 Dockerfile?.我有时也想知道.我正在为 webapp (RStudio-server) 编写一个容器，它允许不同的用户登录，它只是使用来自 linux 机器的用户名和凭据作为有效用户名.这给我带来了想要创建多个用户的可能不寻常的动机.我可以通过只在运行时创建用户来解决这个问题，一切都很好.但是，我使用了一个添加了单个 docker 用户的基本映像，以便它可以交互使用而无需以 root 身份运行(根据最佳实践).这会破坏一切，因为该用户成为第一个用户并最终拥有所有内容，因此在其他用户失败时尝试登录(该应用程序无法启动，因为它缺乏写入权限).让启动脚本运行 chown 首先解决了这个问题，但代价是链接卷更改权限(显然只有在我们链接卷时才会出现问题).

I hear you asking Why do I have such a weird Dockerfile anyway?. I wonder too sometimes. I am writing a container for a webapp (RStudio-server) that permits different users to log in, which simply uses the user names and credentials from the linux machine as the valid user names. This brings me the perhaps unusual motivation of wanting to create multiple users. I can get around this by creating the user only at runtime and everthing is fine. However, I use a base image that has added a single docker user so that it can be used interactively without running as root (as per best practice). This ruins everything since that user becomes the first user and ends up owning everything, so attempts to log on as other users fail (the app cannot start because it lacks write permissions). Having the startup script run chown first solves this issue, but at the cost of linked volumes changing permissions (obviously only a problem if we are linking volumes).

推荐答案

这样对吗?有人可以指出我的文档吗，我只是根据上述实验进行推测.

Is that correct? Can someone point me to documentation of this, I'm just conjecturing based on the above experiment.

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

Perhaps this is just because they both have the same numerical value on the kernel, and if I tested on a system where my home user was not id 1000 then permissions would get changed in every case?

阅读info coreutils 'chown invocation'，这可能会让您更好地了解文件权限/所有权的工作原理.

Have a read of info coreutils 'chown invocation', that might give you a better idea of how file permissions / ownership works.

不过，基本上，您机器上的每个文件都有一组定义其权限和所有权的位.当您chown一个文件时，您只是在设置这些位.

Basically, though, each file on your machine has a set of bits tacked on to it that defines its permissions and ownership. When you chown a file, you're just setting these bits.

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

When you chown a file to a particular user/group using the username or group name, chown will look in /etc/passwd for the username and /etc/group for the group to attempt to map the name to an ID. If the username / group name doesn't exist in those files, chown will fail.

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的用户/组与否.

However, you can chown a file using IDs to whatever you want (within some upper positive integer bounds, of course), whether there is a user / group that exists with those IDs on your machine or not.

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)，否则它可能会成为不同的用户.

The UID and GID bits are set on the file itself, so when you mount those files inside your docker container, the file has the same owner / group UID as it does on the host, but is now mapped to /etc/passwd in the container, which is probably going to be a different user unless it's owned by root (UID 0).

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

The real question is, of course, 'what do I do about this?' If bob is logged in as bob on the given host machine, he should be able to run the container as bob and not have file permissions altered under his host account. As it stands, he actually needs to run the container as user docker to avoid having his account altered.

看来，根据您当前的设置，您需要确保您的 UID >您主机上 /etc/passwd 中的用户名与您的 UID 匹配 >容器中的用户名 /etc/passwd 如果您想以登录主机的同一用户身份与挂载的用户目录交互.

It seems like, with your current set-up, you'll need to make sure your UIDs > usernames in /etc/passwd on your host match up to your UIDs > usernames in your containers /etc/passwd if you want to interact with your mounted user directory as the same user that's logged in on the host.

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

You can create a user with a specific user id with useradd -u xxxx. Buuuut, that does seem like a messy solution...

您可能需要想出一个不挂载主机用户主目录的解决方案.

You might have to come up with a solution that doesn't mount a host users home directory.

这篇关于了解 docker 中的用户文件所有权:如何避免更改链接卷的权限的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！