Docker Compose check · medium
user: root (or 0, 0:0, root:root) makes the service's process run as UID 0. Unless Docker uses user namespaces or runs rootless, that is the same UID as root on the host, limited only by capabilities and security profiles. The explainer flags an explicit root user as medium. It does not flag a missing user key, where the image's own USER applies.
$ explain docker-compose.yml ! app runs as root line 4 fix: see below $
What the free Docker Compose explainer reports on the risky example below.
If the application is compromised, the attacker gets the process's user. As root they can modify any file in the container, install tools, and write to any mounted volume regardless of its file permissions.
Root is also what most container escape techniques start from. Each other loosened setting, such as an added capability or a sensitive mount, is more dangerous when the process is root.
An explicit `user: root` often overrides an image that was built to run as a non-root user, undoing its maintainers' choice.
services:
app:
image: example/app:1.4.2
user: root
restart: unless-stopped
mem_limit: 512m
services:
app:
image: example/app:1.4.2
user: "1000:1000"
restart: unless-stopped
mem_limit: 512m
The risky example is loaded below. Paste your own file to check it for this and every other Docker Compose rule. It runs in your browser; nothing is uploaded.
Parsed in your browser. Nothing is uploaded.
1 service defined: app.
Runs the image example/app:1.4.2.
Runs as user root, which is root inside the container.
If the app is compromised, the attacker has root inside the container, which makes escapes and file tampering easier.
Safer: Set user to an unprivileged UID:GID that owns the files the service needs.
Restarts if it stops or after a daemon restart (unless-stopped), but stays down if you stopped it manually.
Limits memory to 512m. The container is killed if it exceeds this.
By default it is the same UID 0, limited by Docker's reduced capabilities, seccomp and AppArmor. With rootless Docker or user namespace remapping, container root maps to an unprivileged host user.
Add user: "1000:1000" (any unprivileged UID:GID) to the service and make sure that user can write the paths it needs.
No. Without a user key the image's USER applies, which the compose file alone cannot show. It flags only an explicit root, 0, root:… or 0:… value.