[Security Issue] Docker containers' processes run as root #338

New Issue

michael · 2026-01-19T18:29:56Z

michael commented

2026-01-19 18:29:56 +00:00

Originally created by @TheAssassin on GitHub.

(This is the proposal mentioned in https://github.com/dutchcoders/transfer.sh/issues/85#issuecomment-336584896.)

At the moment, the processes in the Docker containers run as root. This is a security problem, as Docker's isolation is not perfect and there's a lot of exploits that could make a root user break out of the container (it's way less of an issue for some random users which are ideally not existing on the host system).

Some links I picked up quite some while ago:

I don't have the time to fix and test this right now. PRs welcome, I guess.

Some drawbacks I experienced earlier which I don't want to withhold (might be useful for the person creating the fix):

When changing the user ID of the processes in the container, the existing volumes (whether it's a named one or a bind mount to a local directory) will require a manual upgrade (changing the owner)
Users trying to use a mount bind might experience issues (especially when that mount is already created but its owner is not set to the Docker process's user ID)

(If I should remember any other ones, I'll post them here.)

You can make it easier for anyone if you pick a very high user ID for the Docker container processes, anything above 10000 should suffice.

Originally created by @TheAssassin on GitHub. (This is the proposal mentioned in https://github.com/dutchcoders/transfer.sh/issues/85#issuecomment-336584896.) At the moment, the processes in the Docker containers run as root. This is a security problem, as Docker's isolation is not perfect and there's a lot of exploits that could make a root user break out of the container (it's way less of an issue for some random users which are ideally not existing on the host system). Some links I picked up quite some while ago: * http://blog.dscpl.com.au/2015/12/don-run-as-root-inside-of-docker.html * https://stackoverflow.com/questions/41991905/docker-root-access-to-host-system I don't have the time to fix and test this right now. PRs welcome, I guess. Some drawbacks I experienced earlier which I don't want to withhold (might be useful for the person creating the fix): * When changing the user ID of the processes in the container, the existing volumes (whether it's a named one or a bind mount to a local directory) will require a manual upgrade (changing the owner) * Users trying to use a mount bind might experience issues (especially when that mount is already created but its owner is not set to the Docker process's user ID) (If I should remember any other ones, I'll post them here.) You can make it easier for anyone if you pick a very high user ID for the Docker container processes, anything above 10000 should suffice.

michael closed this issue

2026-01-19 18:29:56 +00:00

michael commented

2026-01-19 18:29:57 +00:00

@TheAssassin commented on GitHub:

imo it should be up to end user to run the image properly, and images should not enforce uid/gid on their own

That's total nonsense. A Docker image should not be insecure by default. It's considered a best practice to avoid running as root when it's totally unneeded. You can always override the uid/gid, but that's nothing you should have to do to make using a Docker image safe.

Docker environments aren't as isolated as, say, a VM. root can do a lot of harm, even from a container.

Implementing what I suggested is really trivial and increases safety a lot. I would've done it months ago. However, I've never seen a reply like, "ok, let's do it" or "would you be willing to do it".

https://engineering.bitnami.com/articles/why-non-root-containers-are-important-for-security.html
https://medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b

Running as root is only ever a good idea if a tool is specifically meant for that and implements the right protection measures. I'm thinking about apache2, which drops privileges properly for worker processes, or special init daemons that also do this right. Random software should never be run as root for no reason. This applies outside Docker images just like it applies inside them.

@TheAssassin commented on GitHub: > imo it should be up to end user to run the image properly, and images should not enforce uid/gid on their own That's total nonsense. A Docker image should not be insecure by default. It's considered a best practice to avoid running as root when it's totally unneeded. You can always override the uid/gid, but that's nothing you should have to do to make using a Docker image safe. Docker environments aren't as isolated as, say, a VM. root can do a lot of harm, even from a container. Implementing what I suggested is really trivial and increases safety a lot. I would've done it months ago. However, I've never seen a reply like, "ok, let's do it" or "would you be willing to do it". https://engineering.bitnami.com/articles/why-non-root-containers-are-important-for-security.html https://medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b Running as root is only ever a good idea if a tool is specifically meant for that and implements the right protection measures. I'm thinking about apache2, which drops privileges properly for worker processes, or special init daemons that also do this right. Random software should never be run as root for no reason. This applies outside Docker images just like it applies inside them.

michael commented

2026-01-19 18:29:57 +00:00

@stek29 commented on GitHub:

since there are no complex entry points, it should be trivial to set uid/gid manually when starting the container
imo it should be up to end user to run the image properly, and images should not enforce uid/gid on their own

@stek29 commented on GitHub: since there are no complex entry points, it should be trivial to set uid/gid manually when starting the container imo it should be up to end user to run the image properly, and images should not enforce uid/gid on their own

michael commented

2026-01-19 18:29:57 +00:00

@paolafrancesca commented on GitHub:

@stek29 if you are going to suggest how to update the readme I'm happy to do it (you can do as well opening a PR)

@paolafrancesca commented on GitHub: @stek29 if you are going to suggest how to update the readme I'm happy to do it (you can do as well opening a PR)

michael commented

2026-01-19 18:29:57 +00:00

@paolafrancesca commented on GitHub:

That's total nonsense

please, @TheAssassin keep it respectful :)

feel free to open a PR, I'm sorry you were expecting a confirmation for this on my side. If I knew you were I would have given when you opened the issue :)

@paolafrancesca commented on GitHub: > That's total nonsense please, @TheAssassin keep it respectful :) feel free to open a PR, I'm sorry you were expecting a confirmation for this on my side. If I knew you were I would have given when you opened the issue :)

michael commented

2026-01-19 18:29:57 +00:00

@stek29 commented on GitHub:

Maybe updating readme with note about setting uid/gid when starting the container would be enough?

@stek29 commented on GitHub: Maybe updating readme with note about setting uid/gid when starting the container would be enough?

michael commented

2026-01-19 18:29:57 +00:00

@TheAssassin commented on GitHub:

How do you call nonsense nonsense otherwise? I'm not a fan of seeing security concerns not taken seriously or, worse, calling it a user's problem. Blaming the user is always easier than solving an issue properly. This is not a matter of preference or opinion anyway. The principle of least privilege is well established in IT security.

I'll file a PR soon-ish.

@TheAssassin commented on GitHub: How do you call nonsense nonsense otherwise? I'm not a fan of seeing security concerns not taken seriously or, worse, calling it a user's problem. Blaming the user is always easier than solving an issue properly. This is not a matter of preference or opinion anyway. The principle of least privilege is well established in IT security. I'll file a PR soon-ish.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dutchcoders/transfer.sh#338