了解docker中的用户文件所有权：如何避免更改链接卷的权限 [英] Understanding user file ownership in docker: how to avoid changing permissions of linked volumes
问题描述
请考虑以下简单的Dockerfile：
FROM debian：testing
RUN adduser --disabled-password - gecos''docker
RUN adduser --disabled-password --gecos''bob
在一个没有别的工作目录。建立码头图像：
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 。我们试着修正 bob 的主目录的所有权。在容器上运行：
chown -R bob：bob / home / bob
ls -l
，我们看到：
-rw-rw-r-- 1 bob bob 120 Oct 22 03:47 Dockerfile
但是等等！在容器外面，我们现在运行 ls -l </ code>
-rw- rw-r-- 1 1001 1001 120 Oct 21 20:47 Dockerfile
我们不再拥有自己的文件。可怕的消息！
如果我们在上面的例子中只添加了一个用户，一切都会更顺利。由于某种原因，Docker似乎正在进行其所遇到的第一个非root用户所拥有的任何主目录（即使该用户在较早的映像上声明）。同样，这个第一个用户是与我的家庭用户相同的所有权权限的用户。
问题1 是否正确？有人可以指出我的文件，我只是基于上述实验推测。
问题2 ：也许这只是因为它们在内核上具有相同的数值，如果我在系统上测试了家庭用户不是id 1000 那么权限会在每种情况下变化？
问题3 ：真正的问题当然是我该怎么做？如果 bob 以 bob 在给定的主机上，他应该能够以 bob 运行容器，并且没有在他的主机帐户下更改文件权限。实际上，他实际上需要以用户 docker 运行容器，以避免他的帐户被更改。
我听说你问我为什么还有这么奇怪的Docker文件？有时候我也很奇怪我正在为一个允许不同用户登录的webapp（RStudio-server）编写一个容器，它只是使用linux机器的用户名和凭据作为有效的用户名。这给我带来了想要创建多个用户的异常动机。我可以通过仅在运行时创建用户，一切都很好。但是，我使用添加了单个 docker 用户的基本映像，以便可以以交叉方式使用，而不以root身份运行（按照最佳做法）。这样一来，由于该用户成为第一个用户，因此其他用户登录失败（应用程序无法启动，因为它缺少写入权限），因此会遗失所有内容。启动脚本运行 chown 首先解决了这个问题，但以链接卷更改权限为代价（显然只有当我们链接卷时才会有问题）。
是否正确？有人可以指出我的文档，我只是基于上述实验推测。
也许这只是因为它们在内核上具有相同的数值，如果我在家庭用户不是id 1000的系统上进行测试，那么权限会在每种情况下变化？
有一个阅读 info coreutils'chown invocation'，这可能会更好地了解文件权限/所有权如何工作。
但是，基本上，您的计算机上的每个文件都有一组位于其上的位，用于定义其权限和所有权。当您 chown 一个文件时，您只需设置这些位。
当您使用用户名或组名称将一个文件指向特定用户/组， chown 将查找 / etc / passwd 用于该组的用户名和 / etc / group ，以尝试将该名称映射到一个ID。如果这些文件中不存在用户名/组名，则 chown 将失败。
code> root @ dc3070f25a13：/ test＃touch test
root @ dc3070f25a13：/ test＃ll
total 8
drwxr-xr-x 2根根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'
但是，您可以使用ID到任何您想要的文件（当然在某些上部正整数范围内），是否存在用户/组，您可以 chown 存在于您的机器上的那些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
T他的UID和GID位是在文件本身设置的，所以当您将这些文件装载到Docker容器中时，该文件与主机上具有相同的所有者/组UID，现在映射到 / etc / passwd 在容器中，除非由root（UID 0）拥有，否则这可能是一个不同的用户。
当然，真正的问题是我该怎么做？如果bob在给定的主机上以bob方式登录，他应该能够以bob方式运行容器，而不是文件权限在他的主机帐户下被更改。就这样，他实际上需要运行容器作为用户码头，以避免他的帐户被更改。
看起来，使用您当前的设置，您需要确保您的UID>用户名<$ c $您的主机上的c> / etc / passwd 匹配到您的UID>您的容器中的用户名 / etc / passwd 如果要与您的您可以使用具有特定用户标识的用户创建一个具有 useradd -u xxxx的用户，该用户目录与登录主机的用户相同。
。 Buuuut，这似乎是一个混乱的解决方案...
您可能需要提出一个不安装主机用户主目录的解决方案。 >
Consider the following trivial Dockerfile:
FROM debian:testing
RUN adduser --disabled-password --gecos '' docker
RUN adduser --disabled-password --gecos '' bob
in a working directory with nothing else. Build the docker image:
docker build -t test .
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
Who owns the contents of subdir on the container? On the container, run:
cd /home/bob/subdir
ls -l
ad we see:
-rw-rw-r-- 1 docker docker 120 Oct 22 03:47 Dockerfile
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
and we see:
-rw-rw-r-- 1 bob bob 120 Oct 22 03:47 Dockerfile
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!
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.
Question 1 Is that correct? Can someone point me to documentation of this, I'm just conjecturing based on the above experiment.
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?
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.
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.
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?
Have a read of info coreutils 'chown invocation', that might give you a better idea of how file permissions / ownership works.
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.
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'
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
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).
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.
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.
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屋！
