在docker中,在容器内创建的文件在从主机检查时往往具有不可预测的所有权.默认情况下,卷上文件的所有者是root(uid 0),但只要非root用户帐户涉及容器并写入文件系统,所有者就会从主机角度变得或多或少随机.
当您需要使用调用docker命令的同一用户帐户从主机访问卷数据时,这是一个问题.
典型的解决方法是
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的主机用户拥有在卷上生成的文件？
我使用官方的 golang docker 映像来编译我的 go 程序，并将生成的可执行文件放在映射到我的主机目录的卷上。
问题是 docker 生成的文件属于 root:root，这非常烦人，因为我不想通过 sudo 运行我的脚本。
我搜索了使 docker 容器以非 root 身份运行的解决方案，但我发现的方法需要更改 Dockerfile 并将用户添加到映像中，例如
http://gbraad.nl/blog/non-root-user-inside-a-docker-container.html
有没有办法让docker容器以主机上的当前用户身份运行，即用户A运行此镜像将生成属于A:A的文件，用户B生成属于B:B的文件，而A和B都是用户在主机上定义（即卷所在的位置），而不需要通过 Dockerfile 将 A 和 B 添加到映像中？
docker ×2