考虑以下琐碎的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容器中的物品?在容器上,运行:
subdir
cd /home/bob/subdir ls -l
我们看到的广告:
-rw-rw-r-- 1 docker docker 120 Oct 22 03:47 Dockerfile
圣烟!docker拥有内容!回到容器外部的主机上,我们看到原始用户仍然拥有Dockerfile。让我们尝试修复bobhome目录的所有权。在容器上,运行:
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
ls -l
-rw-rw-r-- 1 1001 1001 120 Oct 21 20:47 Dockerfile
我们不再拥有我们自己的文件。可怕的消息!
如果在上面的示例中仅添加一个用户,那么一切将会更加顺利。出于某种原因,Docker似乎会将其遇到的 第一个 非根用户拥有任何主目录(即使该用户是在较早的映像上声明的)。同样, 第一个 用户是与我的家庭用户相同的所有权权限的用户。
问题1 正确吗?有人可以指出我的相关文档吗,我只是基于上述实验进行猜测。
问题2 :也许这仅仅是因为它们在内核上具有相同的数值,并且如果我在我的家庭用户不是id的系统上进行了测试,1000那么在每种情况下权限都会改变吗?
1000
问题3 :当然,真正的问题是,“我该怎么办?” 如果以给定主机上的bob身份登录bob,则他应该能够以该身份运行该容器,bob并且在其主机帐户下没有更改文件权限。就目前而言,他实际上需要以用户docker身份运行容器,以避免更改其帐户。
我听到你在问 为什么我仍然有这么奇怪的Dockerfile? 。我有时也想知道。我正在为一个Webapp(RStudio服务器)编写一个容器,该容器允许不同的用户登录,该容器仅将linux计算机中的用户名和凭据用作有效的用户名。这给我带来了想要创建多个用户的不寻常动机。我可以通过仅在运行时创建用户来解决此问题,一切都很好。但是,我使用的基础映像添加了一个docker用户,因此可以交互使用而无需以root用户身份运行(按照最佳做法)。由于该用户成为第 一个 用户,这破坏了一切 __用户并最终拥有所有内容,因此尝试在其他用户失败时登录(该应用无法启动,因为它缺少写入权限)。chown首先运行启动脚本可以解决此问题,但要以链接卷更改权限为代价(显然,如果我们要链接卷,则只会出现问题)。
chown
那是对的吗?有人可以指出我的相关文档吗,我只是基于上述实验进行猜测。 也许这仅仅是因为它们在内核上具有相同的数值,如果我在我的家庭用户的ID不是1000的系统上进行测试,那么在每种情况下权限都会改变吗?
那是对的吗?有人可以指出我的相关文档吗,我只是基于上述实验进行猜测。
也许这仅仅是因为它们在内核上具有相同的数值,如果我在我的家庭用户的ID不是1000的系统上进行测试,那么在每种情况下权限都会改变吗?
阅读info coreutils 'chown invocation',可能会使您更好地了解文件权限/所有权的工作方式。
info coreutils 'chown invocation'
但是,基本上,计算机上的每个文件都有一组附加的位,以定义其权限和所有权。当您chown创建文件时,只需设置这些位。
当chown使用用户名或组名将文件发送给特定的用户/组时,chown将查找/etc/passwd用户名和/etc/group组,以尝试将名称映射到ID。如果这些文件中不存在用户名/组名,chown则将失败。
/etc/passwd
/etc/group
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,这似乎是一个混乱的解决方案…
useradd -u xxxx
您可能需要提出一种不装载主机用户主目录的解决方案。