Issue when trying to write to a mounted volume from inside a container as a non-root user

Question

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?

Gride

Could you please run ls -l /var/log/zookeeper just after you docker run your container. I wanted to know if the group owner of your mounted volume was staff (like it is on Windows/OS X environment using boot2docker) – Magness

@Magness Inside of the container, it looked like this (which is the same as what I posted originally): drwxr-xr-x 2 106 111 4096 Jun 30 17:18 zookeeper From the host itself, it looked like this: drwxr-xr-x 2 zookeeper zookeeper 4096 Jul 1 23:52 zookeeper Mind you I'm running on Ubuntu so I don't think I would have seen the "staff" group from Windows. – Gride

Answer 1

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.

Allot

Hey, thanks for the answer. Do you know of an easy way of assigning IDs in a "portable" (ie. making sure there won't be conflicts) way? Have you found an easy way of setting up new containers in an automated way such that it reduces the chances of there being id conflicts? – Gride

@massivedynamic good questions... no, I didn't automate that, but I believe it's not difficult to do. – Allot

Found this. Hope helps denibertovic.com/posts/handling-permissions-with-docker-volumes – Bessbessarabia

Answer 2

Very important to see the difference between running a production and a development container. Afaik, there's no real issue if your Docker container runs as root, even on production. However you should never want or need to mount a volume of production. If you want to run it as a zookeeper feel free to do so.

// Edit: The more I read, the more I'm convinced there actually might be a security issue when running stuff as root, so you better not doing so on production.

The solution to try and match uid and gid is viable only for small/local project - it really does make it unportable. You can try and set an arbitrary high uid and gid and then do the same on each of your devs machines, but that doesn't mean it'll always be fine.

tl;dr: On development run chmod -R 0777 on existing files and then umask 0000 to setup permissions on files and directories created later. Then you can mount and edit your files as you please, no matter what user created it.

Gaius