2

Host OS: Debian 11 Bullseye

Docker version: 5:24.0.2-1~debian.11~bullseye

Container OS: Debian 10 Buster


Context

I am trying to containerize an app that I need to persist the state of across container restarts.

It is keeping all of its dynamic data in one directory in /var/lib/.

The simplest solution should therefore be overlaying that directory with a docker volume.

Under standard Docker operation, that isn't an issue, however, due to security concerns regarding potential container compromise and container escape exploits, we'd rather both the Docker daemon and the container app ran under non-root users.


Issue

As the app inside the container should also running as an unprivileged user, I was unable to mount the volume in such a way as for the app user to be able to write into it --

Setting the owner of the folder during the build phase is pointless as it only gets overlayed by the mount when the image is running.

And permissions cannot be changed after the container starts as it's already running in the context of the unprivileged user and the mountpoint is owned by root:root


Question

My question is simple -- Is there any way to achieve a RW volume mount inside the container for an unprivileged user?

4
  • You can specify file permissions in the Dockerfile, you can explicitly set the permissions for the directory in your Dockerfile. Commented May 26, 2023 at 14:37
  • @BlockchainOffice As stated in the post, setting the permissions during build time does not affect the permission set after starting the container and mounting the volume. Running the image with an overriden entrypoint, including the mount and switch to an unprivileged user, I can see the mount is indeed owned as root:root, even if I changed the owner during build time Commented May 26, 2023 at 15:07
  • And if you create a directory with the permissions on the host machine outside of the container and mount that as volume and start your container with -e and -u ? Commented May 26, 2023 at 15:27
  • @BlockchainOffice Already tried aligning the UID inside the container with the user the Docker daemon runs under (Both being 20002), and sadly, that did not work, as the volume still mounts as root. Commented May 26, 2023 at 16:11

1 Answer 1

0

For anyone also looking for a way of accomplishing this, I got there in the end, the way, however, wasn't obvious.

The gist of it is:

  • Run the image as root
  • Set the entrypoint to a script, where you:
    1. First recursively chown the volume mountpoints
    2. Hand the execution over to the primary intended process, changing your user in the process.

I managed the second point using gosu, as using the stock su I just couldn't get working as needed.

A full example of an entrypoint script:

#!/bin/sh
chown -R myAppUser: /var/lib/myAppData 
exec gosu myAppUser /usr/local/bin/myApp --foo=bar

End result: myApp is running under myAppUser, while having full read-write access to the externally mounted volume /var/lib/myAppData, even in a rootless Docker instance.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.