Why Docker’s Default Root User Is a Security Risk: UID/GID Mapping Explained

By default Docker runs container processes as the root user, and this root has the same UID as the host’s root, which can be alarming because the process can potentially control the entire host.

UID and GID Basics

UID and GID are managed by the Linux kernel; the kernel checks them to decide whether a request has sufficient privileges. The kernel works with numeric UID/GID, not with usernames, and the same UID/GID set is shared by all containers on the host because they all use the host kernel.

Therefore, a UID in a container represents the same user as the same UID on the host, even if different usernames are displayed by user‑space tools.

Demo: Root Process in a Container

Running an Ubuntu container with a sleeping process shows the process runs as root:

$ docker run -d --name sleepme ubuntu sleep infinity

On the host, ps aux | grep sleep shows the process owned by root . Inside the container the same applies.

Mounting a host‑only‑root‑writable file into the container proves the container can read and write it, confirming the shared UID/GID.

Specifying a Non‑Root User in Dockerfile

Adding a user in the Dockerfile and using the USER instruction runs the container as that user:

FROM ubuntu
RUN useradd -r -u 1000 -g appuser
USER appuser
ENTRYPOINT ["sleep", "infinity"]

Building the image ( docker build -t test .) and running it ( docker run -d --name sleepme test) shows the effective user is the host user nick (UID 1000). The file created in a mounted volume is owned by appuser , demonstrating that UID 1000 maps to the host’s nick .

Overriding User with --user Flag

Using docker run --user 1000 --name sleepme ubuntu sleep infinity forces the container process to run as UID 1000, overriding the Dockerfile’s USER. Even if no entry exists in /etc/passwd, the process still has the same permissions, showing the username may appear as “I have noname!” but the UID still governs access.

Specifying --user 0 makes the process run as root, overriding any previous user setting.

Conclusion

Containers inherit the host’s UID/GID set, so a process running as root inside a container has the same privileges as the host root. For better security, avoid the default root user by specifying a non‑root user in the Dockerfile or with --user, and consider enabling Linux user namespaces to isolate UID/GID mappings.