Omarchy Spent Fifteen Months Putting Every Desktop Process One Command Away From Root
A Linux distribution built for developers added its default user to the docker group. That made passwordless root available to every process in the session, including the coding agent you left running. The fix shipped August 24.
Run id on your Linux development machine and read the output slowly. Most people never have. That line lists the supplementary groups your login shell belongs to, and every process launched underneath it inherits the entire set: your editor, your browser, your npm postinstall scripts, and the coding agent still working through a task while you make coffee.
On Omarchy, until last Monday, one of those groups was equivalent to root.
The writeup went public August 28, after private disclosure and a patch. The mechanism is old and boring. Omarchy added its default user to the Linux docker group so that docker run would work without sudo. On Arch, the Docker daemon runs as root and listens on /var/run/docker.sock. Anything that can talk to that socket can ask the root daemon to start a container, mount any part of the host filesystem into it, and read or write as root. The proof of concept fits on one line:
docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow
The user process never gains a privilege. It asks a privileged daemon to act on its behalf, and the daemon obliges. Docker documents this exact property in its own post-install guide. The group is understood to be root-equivalent by everyone who has thought about it for five minutes.
So the interesting part is not the socket. It is who was standing next to it.
The list of affected processes starts with agents
When the researcher walked the process tree under the user's systemd --user instance, the docker group showed up on essentially every normal process in the session. Supplementary groups are inherited by children, and there is no point in that chain where anything drops them. The list of places untrusted code could run and reach root opens with AI coding agents and agent harnesses, then browsers, editors, npm scripts, and background daemons.
That ordering is not decoration. It is the sharpest thing in the disclosure, and it points at a gap most people running agents locally have not thought about.
Agent harnesses have permission systems now. In my experience with the ones I run daily, they all reduce to some version of allowlists, denylists, and an approval prompt for commands that look dangerous. Those systems make a decision about which commands execute. They make no decision at all about what credentials the resulting process carries, because they cannot. Permission rules are a policy layer sitting on top of a shell. The kernel's credential set for that shell was fixed at login, by a line in a setup script written fifteen months ago.
Play it out. An agent is allowed to run docker because you told it to work on a project with a compose file, which is entirely reasonable. On a pre-4.0.1 Omarchy box, that permission was not permission to run containers. It was permission to read /etc/shadow, write to /etc/sudoers.d, or drop a systemd unit. The harness saw a docker command on the allowlist and did what you asked.
Or skip the agent entirely and take the more likely path. A dependency in a project the agent is working on runs a postinstall script. It executes as you, with your groups, inside a session where nothing prompts and nothing logs. The researcher's framing is exact: a compromise of a normal user application immediately became a full machine compromise.
The default was made for you, and the manual said the opposite
Two details raise this above a configuration mistake.
The first is that it was opt-out. You did not have to use Docker, or want Docker, or know Docker was installed. The tradeoff was applied to the default account at install time, and nobody was asked. Security-relevant defaults carry weight precisely because most people assume the operating system starts in the safer position and will prompt before moving them out of it.
The second is the documentation. Omarchy's development-tools manual described the group membership like this: the distribution installs "the user group changes needed for you to run Docker as the normal user and not as root." A reasonable person reads "not as root" and concludes something like rootless mode is in play. The plain reading of that sentence is close to the inverse of what the configuration did.
The commit history runs longer than the disclosure suggests. Group membership landed June 1, 2025, was disabled the next day in c5ee230, came back June 17, 2025, and was finally removed on August 24, 2026. Everything before 4.0.1 is affected, and the researcher confirmed it on the latest 3.x ISO, 3.8.4.
Here is the part I did not expect. Go read that manual page now. It has been rewritten, and the new version is better than most security documentation I have seen from any vendor at any size. It states that by default your user is not in the docker group, calls that group "effectively passwordless root," names the exact attack (docker run -v /:/host), and warns that "a single rogue script or dependency running as you would otherwise be one command away from root."
It then explains that you run sudo docker, that the graphical tools prompt for authorization, and that if you want the old convenience back you can enable it deliberately from Setup > Security > Sudoless Docker after a warning. The dangerous setting still exists. It just moved from a default you inherited to a choice you make, with the attack spelled out in the sentence before the button. That is the correct shape of a fix, and it took four days.
Put this into practice
Four things, in order of how little they cost.
Run id. Right now, on every machine where an agent runs. You are looking for docker, lxd, kvm, libvirt, disk, adm, and wheel. Each of those is either root-equivalent or one short hop from it. On a machine you have been using for years, the output is usually a surprise.
Grep your own setup scripts for usermod and gpasswd. Dotfiles repos, provisioning playbooks, that install script you copied from a blog post in 2023. Group additions are written once and never read again, which is exactly why this survived fifteen months in a distribution aimed at developers who read code for a living.
Try Podman on the machine where agents run. It is daemonless. Containers become ordinary child processes in user namespaces, so there is no root socket to reach. The honest cost: swapping runtimes mid-project breaks socket-mounted tooling, anything that shells out to docker by name, and a fair number of compose setups. Do it on the agent box first rather than everywhere at once.
Read your harness changelog for the word "default." Not the features, the defaults. The Omarchy issue was never a bug in anybody's code. It was a line in a setup script whose consequences nobody restated for over a year.
What this does not fix
The group audit closes one specific hole and leaves the shape of the problem intact.
sudo with a cached timestamp is functionally the same exposure, and every developer machine has it. If your agent can run sudo at all inside the sudo timeout window, groups are not what is protecting you. Neither is Podman, which moves the container runtime out of the root path but does nothing about the SSH keys, cloud credentials, and long-lived tokens sitting in plaintext in your dotfiles. Those are the actual prize in most developer-machine compromises, and none of them require root.
The scope claim in the disclosure also deserves a fair reading. "Essentially every process in the session" comes from walking one process tree on one installation, not from a formal audit, and the researcher presents it that way. Nobody has published evidence of this being exploited in the wild against Omarchy users, and absence of evidence is doing real work in that sentence.
I would also push back gently on treating this as an Omarchy story. The docker group has been root-equivalent on every Linux distribution since the daemon shipped, documented as such by Docker, and added by hand by an enormous number of developers who read the same warning and clicked past it. Omarchy's mistake was applying it by default and describing it badly. The rest of us applied it deliberately and described it not at all.
The thing worth carrying forward
Your agent's blast radius is not set in the agent's config file. It is set by the credentials of the process that launched it, which were set by a line in a script you probably did not write, on a machine you have been carrying forward through three laptops.
Every permission dialog you approve is a decision made one layer above the layer that decides what the approval is actually worth. That gap was worth fifteen months of passwordless root on a distribution built specifically for people who should have caught it.
Run id. It takes a second, and the output is a more honest description of what your agent can do than anything in its settings file.
Sources: 0xcc.io, "Omarchy: Any User Process Can Escalate to Root"; Omarchy manual, Development Tools; basecamp/omarchy commit b5ded31; Docker, Manage Docker as a non-root user.