There are recommendations to run processes as a non-privileged user within the docker container:

[...] run your processes as non-privileged users inside the container

See: docs.docker.com, also 1, 2

One reason I can see is that an attacker who got access to the container can install malicous software. However, I run my container with read-only root file systems. So this does not make a difference to me.

Given that I use a read-only root file system, is there any other reason why using a non-root user inside the container would make sense?

To clarify: I am NOT asking about running the docker deamon/starting the container as a non-root user.

  • The read-only file system only matters considering persistence of the damage the attack could do to that container. non-privileged user processes require additional steps to gain full control of the system. Both things should be done, make it necessary privilege escalation to gain control over the system and also the readonly fylesystem to avoid persistence in case of that compromise.
    – bradbury9
    Feb 2, 2021 at 12:48

2 Answers 2


So running a non-root user inside the container (assuming you're not using user namespaces) could still be helpful. There have been some container security issues that required the container to run as root to be effective.

For example abstract shimmer needed to be uid 0 and have host networking to be effective.

Also the runc security issue from 2019 CVE-2019-5736 required the container being exploited to run as root, for the issue to be exploited.

The problem is that, even though docker (and other linux container runtimes) apply restrictions to the running process, being uid 0 can allow for security issues to occur.

Running read-only filesystems is another useful security mechanism and whilst it might make attackers lives harder, it doesn't cover exactly the same ground as using a non-root user inside the container. For example if an attacker can add their exploit to running memory without touching disk, then read only filesystems won't help.

Typically I'd recommend both of these as complementary hardening steps for containers. The other option (instead of using a non-root user inside containers) is using user namespaces, or run the entire docker daemon as a non-root user, which is now a supported option.


Read-only FS will let the attacker read your sensitive files if the container contains something that you don't want to let someone get access to.

The important thing is: The attacker can read your file system, everything that is inside your container, he/she can read it.

So the best practice is to create a restricted user, then you can use docker user namespaces to run the container as the restricted user.

  • Why would I have something in the container that the user of that container is not allowed to read? I would simply not put that in the container then. At all. Do I miss something here? Feb 2, 2021 at 13:02
  • 1
    Usually in a container there's only one user as you say, so file permissions inside the container are less important. Feb 2, 2021 at 21:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .