What's this about?
Omarchy's default configuration put the default user in the Linux `docker` group. On Arch the Docker daemon runs as root and listens on a socket that group members can talk to. So any process in the user's desktop session — not just a shell, everything below it — could ask the root daemon to launch a container, mount the host filesystem into it, and read or write anything as root. No password, no `sudo`, no prompt. The proof of concept is three lines: `cat /etc/shadow` fails, then `docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow` succeeds. Reported privately, patched, and disclosed after the fix. Update to 4.0.1.
Why is "member of the docker group" equivalent to root?
Because the socket is the API to a root process. Anything the daemon can do, you can ask it to do, and the daemon can do everything. Docker's own documentation says so explicitly. The reason this keeps happening is that adding yourself to the `docker` group is the standard, universally-copied fix for "permission denied while trying to connect to the Docker daemon socket" — a papercut solved by silently granting root.
What's the community saying?
- The immediate technical answer is rootless Podman, which the disclosure itself recommends; the counter-argument is that rootless containers add real runtime friction that an opinionated, developer-experience-first distribution may not accept.
- That produces the thread's genuine disagreement: whether Arch culture optimises for the wrong kind of simplicity — implementation simplicity — in a way that avoids grappling with this class of problem.
- Supplementary groups are inherited by child processes, which is why the scope is the whole session rather than one terminal — the part most people underestimate.
- A large chunk of the thread is about DHH personally rather than the bug, which is worth knowing before you go in expecting a technical discussion.