当尝试以非root用户的身份从容器内写入已装载的卷时出现问题 [英] Issue when trying to write to a mounted volume from inside a container as a non-root user

查看:166
本文介绍了当尝试以非root用户的身份从容器内写入已装载的卷时出现问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用一个将运行ZooKeeper的容器,但是我遇到了我挂载到容器中的主机卷上的权限问题。



这是我的设置:



在主机(Ubuntu 14.04)上:




  • 创建zookeeper系统用户(id = 106)和组(id = 111)。

  • 创建目录/ var / log / zookeeper并将其所有权设置为zookeeper(即chown zookeeper:zookeeper)。这是我将放入我的容器的目录。



容器内容(Ubuntu 14.04):




  • 还创建了一个zookeeper系统用户(id = 102)和组(id = 105)要在ENTRYPOINT中执行命令。

  • 创建将要挂载的目录/ var / log / zookeeper,并将其所有权设置为zookeeper:zookeeper(尽管我一旦我用/ var / log / zookeeper mount启动了我的容器,我打开了一个作为zookeeper用户(在容器内部创建)的容器内部的shell,如果我尝试在挂载的目录/ var / log / zookeeper中创建一个文件,我发现我有一个权限被拒绝错误。当我做一个ls -l来查看这个目录(仍然在容器内)的所有权时,它看起来像这样:

      drwxr-xr-x 2 106 111 4096 6月30日17:18 zookeeper 

    而在这种情况下,111对应于我认为是问题所在的主机的动物园管理员用户和组ID。我试图在容器中打开一个shell,但是这次我以root用户身份进入,上面描述的场景完全正常,只是root是创建的文件的所有者(预期)。



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



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



    (b)创建一个zookeeper用户并对其进行分组在我的主机和容器中的id完全相同的



    两种情况都是理想的,因为(a),运行应用程序因为root用户可能会遇到潜在的安全问题(从我看过的内容),而对于(b),可能非常难以获得id匹配,因为他们可能会已经被创建的其他用户(您没有任何控制权)已被占用。



    有没有人曾经处理过这样的事情?是否有其他可能的解决方案,我可能会忽视?

    解决方案

    据我所知,容器内的用户ID和组ID主机应该匹配,以便让主机授予您权限的共享目录。


    I'm working with a container that will be running ZooKeeper but I'm running into issues with permissions on the host volumes that I mount into my container.

    This is my setup:

    On the host machine (Ubuntu 14.04):

    • Created a "zookeeper" system user (id=106) and group (id=111).
    • Created the directory "/var/log/zookeeper" and set its ownership to zookeeper (ie. chown zookeeper:zookeeper). This is the directory that I will be mounting into my container.

    Inside the container (Ubuntu 14.04):

    • Also created a "zookeeper" system user (id=102) and group (id=105) which I use as the user from which to execute the command in the ENTRYPOINT.
    • Create the same directory "/var/log/zookeeper" that will be mounted to and also set its ownership to zookeeper:zookeeper (although I don't think this matters).

    Once I start up my container with the /var/log/zookeeper mount and I open up a shell inside of the container as the zookeeper user (that was created inside the container), I find that I get a "Permission Denied" error if I try to create a file in the mounted directory /var/log/zookeeper. When I do an "ls -l" to look at the ownership of this directory (still inside of the container) it looks something like this:

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

    The 106 and 111 in this case correspond to the zookeeper user and group ids of the host machine which I think is where the issue lies. I tried opening a shell inside of the container but this time I went in as the root user and the scenario that I described above worked perfectly fine just that root was the owner of the file that got created (which was expected).

    From this I concluded that I need to either:

    (a) Run the application inside of my container as the default root user instead of the zookeeper user that I create.

    (b) Create a zookeeper user and group both on my host machine and inside the container whose id's are exactly the same.

    Neither case is ideal because for (a), running the application as the root user could have potential security issues (from what I've read anyways), and for (b), it can be very difficult to get the id's to match due to the fact that they might already be taken by other users that were created (which you don't have any control over).

    Has anyone ever dealt with something like this before? Are there other possible solutions that I might be overlooking?

    解决方案

    To my knowledge, user ID and group ID inside the container and on the host machine should match, in order to let the host machine to grant you permissions to the share directory.

    这篇关于当尝试以非root用户的身份从容器内写入已装载的卷时出现问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆