TL;DR

In Command-line Docker Applications we laid out an issue about running Docker images for daily jobs that have to work on files in the host. Here’s one possible way forward, if you trust starting your containers as root.

The solution I usually adopt is to rely on a wrapper shell script inside the container, to be run as root. It will make sure that there is a user inside the container matching the requests from the outside (this is flexible) and then it will run the real command as that user, using su-exec to avoid having intermediate executors.

The wrapper itself is included in the repository dibspack-basic as suexec. It still does not have proper documentation (my fault!) but you can see it in action here:

So… the wrapper makes sure that there is a suitable user inside the container, even though the image was not created with that user inside in the first place.

(If you’re wondering, yes the test image above is available at polettix/docker-mismatch with tag alt-1.0).

Of course there’s a drawback: the container has to be started with user root (see the -u root in the asciinema above?), so that it can manipulate /etc/passwd (if needed) and do the magic.

In a service/generic setup this would be a big, Big, BIG problem: we should always strive to run containers with the least privilege needed. In this case, though, we’re talking about running interactive commands… so your mileage may vary depending on the host you are on and the permissions that have been granted.

In a virtual machine inside your PC… I guess it’s OK. What do you think?