Why the docker group hands users root, and how rootless containers avoid it

A recently disclosed vulnerability in one of the newer Linux distributions has put a long-standing Docker weakness back in the spotlight. Writing on his blog, in an essay that reached the front page of Hacker News, Miguel Grinberg argues that the incident — caused by an installer that silently applied a non-standard, risky Docker configuration — should push more people toward running containers without root.

According to Grinberg, the flaw let any process on an affected machine raise itself to root with no password, no sudo and no prompt. The root cause was not a bug in container code but a default that made the docker command usable without elevated privileges.

Why Docker's root daemon is a liability

Docker's security troubles trace back to its client-server architecture, Grinberg explains. The daemon runs in the background as root and serves an API over the Docker socket, which clients such as the docker CLI talk to. Because the daemon is root, anyone who can reach it can execute code with full system privileges.

He demonstrates the point on an Ubuntu 26.04 machine. Listing the contents of /etc/sudoers.d fails for a regular user, but the same listing succeeds when issued through a container that bind-mounts the host's entire filesystem. The container inherits the daemon's root privileges, so the invoking user's own restrictions do not apply — and no password is requested. A slightly more developed script, he notes, could rewrite system files, plant cron jobs or exfiltrate data unnoticed.

There is a caveat: on a default Docker install, only root can invoke docker, so the trick has nowhere to land. The exposure appears when that restriction is relaxed for convenience — most commonly by adding a user to the docker group so sudo is unnecessary. That step is described in Docker's own documentation, and Grinberg suspects most Linux Docker users have taken it. The distribution behind the recent vulnerability essentially did the same thing for its users, without telling them.

macOS, Windows and WSL

Docker itself only runs on Linux. Products such as Docker Desktop on macOS and Windows host a Linux virtual machine to make it work, and Grinberg — who says he is not deeply familiar with these setups — expects that extra layer of separation to reduce the danger to the host considerably. WSL on Windows is different: the Linux kernel runs directly on the host with tight OS integration, so he treats it as carrying risks closer to those of a native Linux system.

The rootless options

Grinberg highlights two alternatives:

• Docker's rootless mode runs the daemon as a user-level service. He finds the setup clumsy: install Docker normally, disable the system daemon by hand, then run a supplied script that stands up a per-user replacement.
• Podman removes the daemon entirely. Install it and it works, with no background service required. Swap docker for podman on the command line — or alias one to the other — and, in his experience, the large majority of workflows behave identically, while containers run under your own account with no root-owned daemon to abuse.

Where Podman breaks compatibility

• Registry handling: pulling an image by its short name, such as postgres, can fail because Podman does not always default to Docker Hub depending on configuration. Grinberg's advice is to use fully qualified addresses such as docker.io/library/postgres.
• Reboots: with no daemon, containers are not automatically restarted after a reboot, so always-on servers need extra setup — Podman's systemd integration via the quadlet commands can register containers as individual services.
• API users: applications that drive containers through the Docker API can rely on Podman's optional compatibility service, started with podman system service.

Why it matters

The vulnerability that prompted the essay stemmed from a configuration choice, not an exotic exploit — and the same choice is documented and routinely made by hand. Membership in the docker group is functionally equivalent to root, which makes it a quiet risk on developer machines and CI hosts alike. Rootless setups, whether Podman or Docker's rootless mode, eliminate that entire class of privilege-escalation problems rather than patching them one by one. Grinberg's closing argument is simple: if you run containers on Linux, run them without root.