Published on Aug 30th, 2026.
View link on 0xcc.io.
This is one of those things that I sorta knew in the back of my head seemed fishy but never fully grasped the security implications of. From 0xcc.io:
The Issue
Omarchy configured its default user as a member of the Linux
dockergroup.That allows users to run commands such as:
without typing
sudo.On arch the Docker daemon runs as root and listens on:
Members of the
dockergroup can communicate with that socket. Docker itself explicitly warns that thedockergroup grants root-level privileges to the user.A process with access to the Docker socket can ask the root-owned Docker daemon to launch a container as root, mount arbitrary portions of the host filesystem into it, operate on those files as root, and run code as root.
On affected Omarchy systems, this means that the default user and all processes launched in that user session have access to root.
Look, I dislike Omarchy1 and especially DHH as much as the next politically aware engineer, but I’ll be darned if I didn’t admit that I have been slapping the docker group onto my normal user this whole time.
I’m willing to admit this publicly because I’m sure many others do the same without realizing the full security implications of this seemingly mundane decision to improve convenience. As the article mentions, it’s especially relevant given that many are also now running LLM coding harnesses with full shell access under our users. Yikes! Thankfully there’s an easy fix:
$ gpasswd --delete steve docker
Relatedly, I’ve recently migrated much of my self-hosted setup over to Podman, which apparently is a little better about this by not requiring a root-owned socket by nature of being daemon-less (source). This is great for security, but I also really like being able to keep everything in systemd + *.container unit files rather than a separate world of docker compose YAML and the docker process manager.
Perhaps worth experimenting with if this was as much of a kick in the teeth to you as it was to me.