在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的主机用户拥有在卷上生成的文件？
docker ×1