我正在重新映射Docker用户命名空间:https://docs.docker.com/engine/security/userns-remap/
我已经通过修改/etc/docker/daemon.json
启用了Docker用户命名空间重映射。当前内容如下:
{
"userns-remap": "default"
}
我已经重新启动了Docker守护进程。默认的dockremap
用户是按照文档的承诺创建的:
user@host:~$ id dockremap
uid=125(dockremap) gid=134(dockremap) groups=134(dockremap)
/etc/subuid
:中也有一个条目
dockremap:165536:65536
现在,我有一个文件夹,里面有一个共享文件,我希望将它绑定到一个容器中,以便可以读取。在主机操作系统上,文件具有以下所有者和权限设置:
-rwxrwx--- 1 dockremap dockremap 0 april 8 19:19 shared_file.txt
该文件不应该是全局可写的。我的实际意图是在主机操作系统和容器之间安全地共享一个文件,其中包含一些秘密信息。
如果父目录有任何不同,那么它是完全可写的:
drwxrwxrwx 3 dockremap dockremap 4,0K april 8 19:20 .
我把它绑在一个阿尔卑斯山集装箱里,就像这样:
docker run --rm -it -w /work -v $(pwd)/shared_file.txt:/work/shared_file.txt remaptest ls -lah
我现在希望该文件由容器中UID为0的root
所有,因此可以读取。相反,它归nobody
所有,root
:不可读
-rwxrwx--- 1 nobody nobody 0 Apr 8 16:19 shared_file.txt
容器内的nobody
具有以下ID:
/work # id nobody
uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)
我对用户命名空间重新映射和绑定装载文件系统权限如何协同工作有错误的期望吗?还是这里有问题?我在两台不同的电脑上测试过,一台运行Ubuntu,另一台运行Mint。
我还用Ubuntu-based
容器而不是Alpine-based
容器进行了测试,但结果基本相同。当然,我可以修改用于构建图像的Dockerfile,但我认为上面的方法应该有效。
我想使用的实际Dockerfile
来自Docker Hub,我不想破坏它的设置方式。
让我首先说,在我自己非常有限的经验中,我发现用户命名空间映射是一个特别难以理解的主题,尤其是在使用docker时。我个人觉得,有错误的期望几乎是故意的。但它仍然是一个强大的工具
发生了什么
在您的情况下,我会尝试将$(pwd)
作为/work
(而不仅仅是文件(安装到容器中,并运行touch /work/test.txt
。在您的主机上,您会看到这个文件是由一个用户在运行ls -lan $(pwd)
时使用uid165536
创建的。这正如您的主机/etc/subuid
文件中所述,但我同意这不一定是您所期望的。
可以做些什么
为了解决这个问题,我在/etc/subuid
中更改或准备映射。例如,您可以在dockremap:165536:65536
之前添加一行,说明dockremap:125:1
。由于主机上dockremap
的uid是125
,并且您只想映射这一个uid,所以这一行应该可以完成任务。
现在,如果使用新文件再次进行touch
测试,您将看到您的文件由主机上的125
(又名dockremap
(和容器中的0
(又名root
(所有。
进一步阅读
我可以推荐这篇文章:https://www.jujens.eu/posts/en/2017/Jul/02/docker-userns-remap/