Don't run as root in docker / How to run it more "securely"

[dzek69]

Running this image is insecure by defult: ​https://engineering.bitnami.com/articles/why-non-root-containers-are-important-for-security.html

It can be worked around with a solution that can't be applied anywhere so it's often not a way to go:
https://dreamlab.net/en/blog/post/user-namespace-remapping-an-advanced-feature-to-protect-your-docker-environments/

Please consider making a fix.

I have forked this project and did the fix for my own purposes but I don't know every possible consequence of doing that because I don't know how this app works and I don't know much about Python, so I haven't opened a PR, but if you want to take a look - you're welcome. It works for me flawelessly and it SHOULD work for everyone as well.

However migration for the users with directory mounts will require manually changing the ownership of the files (now owned by root)

[dtomlinson91]

I wouldn't go so far as to say that the image is insecure by default, unless you consider Docker itself insecure in which case you should run it bare metal.

Although I do agree that if a container does not need to run as root, you should build it with this in mind. There are also limitations to user namespace remapping.

The problem with proposing a change is that the readme proposes using a Docker volume, which as far as I understand cannot be mounted as a non-root user (moby/moby#2259 is still open).

Have you tried applying your Docker image on top of v0.38.1? Does it work? Since volumes are not mounted in a docker build and when you run the container the contents of the volume will be copied into the image I would have thought that they will be owned as root. Permissions are only propagated to the volume on creation and changing these must be done by the Docker engine.

Running chown on /var/lib/docker/volumes/* isn't really a solution to propose.

The only workaround I can think of would be to keep the image as root, create the app user, edit the entrypoint to change the permissions to this new user, switch to a less privileged user, and finally run the app.

[dgtlmoon]

The only workaround I can think of would be to keep the image as root, create the app user, edit the entrypoint to change the permissions to this new user, switch to a less privileged user, and finally run the app.

yeah that's sort of where my mind is going too, I like moby/moby#2259 because it's talking about the core problem, not how to 'fix' it

[dgtlmoon]

You know there was also #95 in which use

environment:
  - PUID=1000
  - PGID=1000

[dgtlmoon]

However migration for the users with directory mounts will require manually changing the ownership of the files (now owned by root)

YES, this was a real pain in the ass decision from the start (also known as technical debt), so maybe the first step is to find a way to change this for users, maybe the Dockerfile can change this when it starts?