User permissions inside and outside of LXC containers?

Question

I'm running some services inside of Docker LXC containers on my server and I'm beginning to actually do serious things with them.

One thing I'm not clear on is how user permissions work inside and outside of the container. If, for example, I'm running MySQL in a container and have its data directory set to /data, which is a Docker volume, how do permissions inside and outside of the container affect access policies?

Obviously, the idea is to run MySQL as its own user in the container (ie mysql:mysql) and give it read and write rights to that directory. I assume that this would be fairly straightforward, just chmoding the directory, etc. But how does this work outside of the container? Now that I have this Docker shared volume called 'data,' how do I manage access control to it?

I'm specifically looking to be able to run an unprivileged user outside of the Docker container which will periodically access the MySQL shared volume and backup the data.

How can I setup permissions, users, and groups so that a specific user on the host can read/write files and folders in the Docker shared volume?

Answer 1

Since the release of 0.9 Docker has dropped LXC and uses its own execution environment, libcontainer. Your question's a bit old but I guess my answer still applies the version you are using.

Quick Answer: To understand the permissions of volumes, you can take the analogy of mount --bind Host-Dir Container-Dir. So to fulfill your requirement you can use any traditional methods for managing permissions. I guess ACL is what you need.

Long Answer: So as in your example we have a container named dock with a volume /data.

docker run -tid --name dock -v /usr/container/Databases/:/data \
    centos:latest /bin/bash

Inside the container our MySQL server has been configured to use the /data as its data directory. So we have our databases in the /data inside the container. And outside the container on the Host OS, we have mounted this /data volume from /usr/container/Databases/ and we assign a normal user bob to take backups of the databases. From the host machine we'll configure ACLs for user bob.

useradd -u 3000 bob
usermod -R o=--- /usr/container/Databases/
setfacl -R -m u:bob:rwx /usr/container/Databases/
setfacl -R -d -m u:bob:rwx /usr/container/Databases/

To test it out lets take a backup with user bob.

su - bob
tar -cvf container-data.tar /usr/container/Databases/

And tar will list out and you can see that our user was able to access all the files.

Now from inside the container if you check with getfacl you will notice that instead of bob it shows 3000. This is because the UID of bob is 3000 and there is no such user in the container so it simply displays the UID it receives from the meta data. Now if you create a user in your container with useradd -u 3000 bob you will notice that now the getfacl shows the name bob instead of 3000.

Summary: So the user permissions you assign from either inside or outside the container reflects to both environments. So to manage the permissions of volumes, UIDs in host machine must be different from the UIDs in the container.