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 chmod
ing 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?
Best Answer
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
.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.To test it out lets take a backup with user bob.
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 withuseradd -u 3000 bob
you will notice that now thegetfacl
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.