相关疑难解决方法(0)

在docker中,在容器内创建的文件在从主机检查时往往具有不可预测的所有权.默认情况下,卷上文件的所有者是root(uid 0),但只要非root用户帐户涉及容器并写入文件系统,所有者就会从主机角度变得或多或少随机.

当您需要使用调用docker命令的同一用户帐户从主机访问卷数据时,这是一个问题.

典型的解决方法是

• 在Dockerfiles中创建时强制用户uID(非可移植)
• 将主机用户的UID docker run作为环境变量传递给命令,然后chown在入口点脚本中的卷上运行某些命令.

这两种解决方案都可以控制容器外的实际权限.

我希望用户命名空间是这个问题的最终解决方案.我已经使用最近发布的版本1.10和--userns-remap设置到我的桌面帐户运行了一些测试.但是,我不确定它是否可以使安装卷上的文件所有权更容易处理,我担心它实际上可能正好相反.

假设我启动这个基本容器

docker run -ti -v /data debian:jessie /bin/bash
echo 'hello' > /data/test.txt
exit

然后检查来自主机的内容:

ls -lh /var/lib/docker/100000.100000/volumes/<some-id>/_data/

-rw-r--r-- 1 100000 100000 6 Feb  8 19:43 test.txt

这个数字'100000'是我的主机用户的子UID,但由于它与我的用户的UID不对应,我仍然无法在没有权限的情况下编辑test.txt.此子用户似乎与docker之外的实际常规用户没有任何关联.它没有映射回来.

由于UID->sub-UID名称空间中发生的映射,本文前面提到的由主机和容器之间的UID对齐组成的变通方法不再起作用.

那么,有没有办法在启用用户命名空间的情况下运行docker(为了提高安全性),同时仍然可以让运行docker的主机用户拥有在卷上生成的文件？

我有一个包含日食的码头图像.我在一个名为eclipse的帐户下运行图像中的eclipse.我想用我的工作区目录启动映像,将主机绑定到容器中.不幸的是,容器内安装的卷的所有者不是日食.安装的卷只保留主机的UID和GID.

有没有办法控制UID和GID是容器中安装的卷？

我正在尝试Docker 的userns-remap功能，以root用户身份在容器内创建一个文件，并test以主机上的用户身份拥有此文件的所有者。

我已将以下内容添加到 /etc/docker/daemon.json

{
  "userns-remap": "test:test"
}

重新映射似乎是根据守护程序日志进行的

User namespaces: ID ranges will be mapped to subuid/subgid ranges of: test:test

和条目test:100000:65536，并test:100000:65536已被添加到/etc/subuid和/etc/subgid/分别文件。

但是当我启动一个容器并尝试在工作目录中创建文件时，它失败了

test@box:~$ docker run -v /home/test/tmp:/somedir -w /somedir -it ubuntu:16.04 /bin/bash
root@11ff6c42ffe1:/somedir# touch file.txt
touch: cannot touch 'file.txt': Permission denied

root@11ff6c42ffe1:/somedir# ls -l
total 0
-rw-rw-r-- 1 nobody nogroup 0 Mar 23 21:39 already_existing_file.txt

root@11ff6c42ffe1:/somedir# id root
uid=0(root) gid=0(root) groups=0(root)

root@11ff6c42ffe1:/somedir# touch /file.txt

可以按预期在未从主机挂载的其他目录中创建文件。 …

我正在使用一个将运行ZooKeeper的容器,但是我遇到了关于我装入容器的主机卷的权限问题.

这是我的设置:

在主机上(Ubuntu 14.04):

• 创建了"zookeeper"系统用户(id = 106)和组(id = 111).
• 创建目录"/ var/log/zookeeper"并将其所有权设置为zookeeper(即chown zookeeper:zookeeper).这是我将安装到容器中的目录.

容器内部(Ubuntu 14.04):

• 还创建了一个"zookeeper"系统用户(id = 102)和group(id = 105),我将其用作在ENTRYPOINT中执行命令的用户.
• 创建将要挂载的相同目录"/ var/log/zookeeper",并将其所有权设置为zookeeper:zookeeper(虽然我认为这不重要).

一旦我使用/ var/log/zookeeper mount启动我的容器,我在容器内部打开一个shell作为zookeeper用户(在容器内创建),我发现我得到一个"Permission Denied"错误,如果我尝试在挂载目录/ var/log/zookeeper中创建一个文件.当我执行"ls -l"查看此目录的所有权(仍然在容器内)时,它看起来像这样:

drwxr-xr-x 2  106  111   4096 Jun 30 17:18 zookeeper

在这种情况下,106和111对应于主机的zookeeper用户和组ID,我认为这是问题所在.我尝试在容器内部打开一个shell,但这次我以root用户身份进入,上面描述的场景完全正常,只是root是创建的文件的所有者(这是预期的).

由此我得出结论,我需要:

(a)在我的容器内运行应用程序作为默认的root用户,而不是我创建的zookeeper用户.

(b)在我的主机上和id完全相同的容器内创建一个zookeeper用户和组.

这两种情况都不理想,因为对于(a),以root用户身份运行应用程序可能存在潜在的安全问题(从我已经阅读过的内容),对于(b),要使id匹配到期可能非常困难事实上,他们可能已被其他已创建的用户(您无法控制)使用.

有没有人曾经处理过这样的事情？我可能会忽略其他可能的解决方案吗？