What is a prescriptive way for managing the permissions for mounted volumes in Alpine-based Docker?

Question

When you build an image you can assign ownership (chown) and change permissions (chmod) of paths within the image. However, when a volume is mounted from either the host or another container the permissions for that volume are present, potentially introducing a user/group unknown to the container it is mounted within.

I'm interested in a prescriptive method (if one exists) to handle permissions for users under an Alpine Docker image for both host mounted and container mounted volumes.

The two possible options that I can think of are:

1. Use the same user and group between containers and mounted volumes.
2. Use ACLs to control the permissions.

Is there a recommended approach for addressing permission issues for mounted volumes, especially when the uid/gid of the owners does not match with users/groups inside of a container? E.g.

Within my Alpine Docker image my www-data user has a uid/gid of 82 (see: nginx www-data user id), if I mount a volume from another container or the host where a user with the uid 1001 and gid 1001 owns the volume, how do I deal with the disparity in ownership and permissions?

---

NB: Some application frameworks (e.g. Symfony) recommend using something like setfacl [1] to manage permissions, but this does not seem to be possible under an Alpine Docker image with AUFS because the operation is"not supported".

Is using ACLs an anti-pattern in Docker?

Answer 1

NB: StackOverflow has the following question: What is the best way to manage permissions for docker shared volumes? which is similar to the above and numerous answers, with the prevailing answer being this one.

From experimentation and reading numerous sources looking for a prescriptive answer or common pattern I've identified the following:

When running Docker-outside-of-Docker (DooD) host data volumes are mounted from the underlying host. I remember stumbling across some mention of this in a blog post, but for the life of me I can't find it now (If/when I do, I'll update this answer). The long and short of it is this: when you're running Docker through a shared docker.sock within a container, Docker is going to attempt to mount volumes from the underlying host. If you mount volume(s) from another container you don't have this issue.

Assigning permissions and ownership. The issue I noted above (with setfacl not working) appears to have been a user issue. I must have been trying to run it under the permissions of the non-root user or against a directory that my user did not have ownership of. In order to get around ownership issues you can use a docker-entrypoint.sh script that will either chown or setfacl as the root user before executing the command as the user for the image. As of yet I've identified two feasible options to handle ownership and permissions issues:

• Use sudo to change ownership or set access control lists.
• Allow your container to run using the root user and then step down to another user to execute the command using gosu or su-exec.

---

I took to combining the two observations above for my self-prescriptive approach, so...

1. Whenever mounting a host volume in a Docker container that also shares the docker.sock with the host, it is advised that the directories should match. For example, if the volume mount in the Dockerfile is declared as /var/data then mount /var/data from the host (e.g. -v /var/data:/var/data). This is especially if you have files or directories under /var/data that you will want to mount from within the container in a new container.
2. Be proactive about permissions, always include a docker-entrypoint.sh file that at the very least updates the ownership or access control for a mounted directory.