Don't use vibecoded distros. It doesn't matter whether they fix this or that, or whether you care about a particular vuln. This is not sensible. It's why you switched away from Windows in the first place, remember?
"Someone" didn't find that, AI found it. So it's not clear what your point is about vibe coding. Would humans have noticed this problem, especially given that it's not remotely exploitable? (you have to plug in a malicious USB device).
I saw a couple video demos recently, and was horrified that it seemed one had to memorize a dozen key binding shortcuts to really use it. Is that rather common now? I'm just a Gnome pleb who prefers discoverability via UI.
Well the whole point is to have a good foundation and then make it actually yours, and the only necessary key binds are probably SUPER+K for the key bind cheatsheet and SUPER+SPACE for the menu.
Also the community is large so there's usually someone that has already had your issue and resolved it. The amount of themes and plugins are growing everyday.
A bare arch+hyprland install really feels terrible to use and has a much larger barrier to entry than Omarchy.
You didn't switch away from windows to get superior software?
Also, the statement was valid because it will be true for most. It doesn't matter that you read it and it wasn't true for you, as long as it's true by the numbers, it's true, because it's one-to-many communication not one to one.
While I don't want to discuss the quality of any distro vs Windows, there is a big reason most of us use free software: because it is free.
Whether for you it is because of free as in freedom or free as in beer specifically, quality may not have much to do with it.
This seems to be quite contrarian considering we had this on the front page of HN the other day: "Debian votes to allow "responsible use of generative AI".
I guess this LLM coding wasn't "Responsible" enough. hahaha
Omarchy is all in on AI, if you look at the recent commits and the dev workflows they have set up you can easily tell no human is looking at all the stuff they are merging.
It's not the same thing as allowing some AI contributions under strict guidelines.
I think this is more about the UI, rather than the install. I haven't tried it myself though.
I think nowadays using quickshell anyone who is so inclined can vibecode their own UI though. I recently made the switch to Wayland/hyprland and rebuilt my polybar on quickshell, even adding widgets that allow getting system info/fine grained system control (interactive Bluetooth, WiFi, Volume, Brightness etc).
Even if you introduce bugs in your UI (which I think is not very likely if you have a basic understanding of your system), the chance that someone would exploit software that literally only runs on your own machine seems extremely unlikely to me.
Add that annoying theo guy to that list. Cant stand these people, they confidently push out videos like they're experts, a week later it turns out whatever they were talking about was total crap and they've already abandoned it - case in point OpenClaw. Look at the mess of videos those named above put out about it, not a single one uses it anymore.
There is only so much a human can master in his lifetime. And if you choose to master the art of video production, then you are probably not spending that much time on mastering the thing you yap about on camera…
UI is desktop environment and (usually) ports to large-use distros cleanly.
- JaKooLit’s Fedora-Hyprland Repository: https://github.com/JaKooLit/Fedora-Hyprland. The most popular automated setup guide and installer for Fedora, bundling Hyprland alongside pre-configured bars, launchers, and
- Official Hyprland Wiki: wiki.hypr.land/Getting-Started/Installation/. The main reference guide for core configuration options, environment variables, and Wayland portal requirements.
- Solopasha Fedora COPR copr.fedorainfracloud.org/coprs/solopasha/hyprland. The primary community repository hosting cutting-edge builds of Hyprland and its ecosystem packages for
- Fedora Discussion Tutorials: discussion.fedoraproject.org. Community walkthroughs covering minimal netinstall setups and distro-specific Wayland troubleshooting.
"Archlinux is much easier to install nowadays" is not really the point.
Arch is a more general purpose distro. As a developer who mostly wants a Mac-like Linux distro without the associated noise, if you encounter a problem with Arch and ask about it, you will probably get a lot of irrelevant opinions from all sorts of people that run Arch on everything from embedded devices to large servers. In a different way you can see this in this thread where instead of discussing why Omarchy has the bug (guess what, "default user and all processes launched in that user session have access to root." is a convenience that a lot of developers would like to have), people are recommending their favorite distro instead.
Even though I don't like DHH much, what Omarchy is offering is a user experience that is built with a specific sort of developer in mind; the kind that used to use Linux, moved to Macs for the convenience, and would like that convenience replicated on a Linux distro. That's why people use Omarchy specifically rather than Arch, not the YouTube stuff. I think CachyOS was the equivalent for gamers.
> As a developer who mostly wants a Mac-like Linux distro without the associated noise
I'm required to use Ubuntu at work. Coming from Mac, apart from the menu bar at the top, on Gnome, I've been able to customize the keyboard shortcuts, remap the keyboard so that Ctrl works like Cmd, and use extensions like Dash to Dock[1] and themes like Whitesur[2] to replicate something that almost works like a Mac.
The keyboard remapping and customizing keyboard shortcuts were all done within default the default settings app.
The only things missing are some keyboard shortcuts like Ctrl+A/V to move to the beginning and end, and the Ctrl+Shift+C/V behavior on the terminal instead of Cmd+C, which I've just worked around by using VSCode's terminal and configuring it to copy when I press Ctrl+C with some text selected.
Homebrew is like giving a bunch of wikipedia randos remote shell access to your computer. There is no enforced code review policy. Any maintainer can make a commit under a pseudonym and merge their own code to main without review.
Homebrew should not be allowed near any machine you need to be able to trust.
> In a different way you can see this in this thread where instead of discussing why Omarchy has the bug
There's nothing interesting to discuss. Rootless OCI-compliant containers exist, and Omarchy ignored them. The "convenience" of the solution they chose simultaneously opens an enormous attack surface that the maintainers didn't consider.
This is why I don't believe the "give me a macOS distro" people - even Apple wouldn't do this. If you want a preconfigured Mac-like distro, then you should use GNOME and not a pre-riced desktop with hundreds of dotfiles. You don't have to use Arch either, you can go with a graphical install of Fedora or CachyOS if you want. This will give you a system that you can understand, maintained by people with a minimum standard of quality, that actually resembles the workflow of macOS. There is no Niri or Sway rice that will magically make your system make sense, and this is why I think a lot of the Mac and Windows expats should just use a normal desktop.
> if you encounter a problem with Arch and ask about it
It's probably already documented on Arch wiki or it's a generic Linux issue that has already been solved by someone (that has been my experience with Cachy).
Omarchy imo is best for agent maxxing Mac power users who aren't locked into Apples proprietary apps like Final Cut, audio production software or Adobe and Affinity, so maybe not so great for designers and photographers as the main system.
Docker can be run rootless. It is so easy. No excuse for desktop distros to not do this by default. And that is why all major Linux distros are just as bad as Omarchy (Not recommending MacOS or Windows either as those are wildly worse)
>when it’s a very common setup to add regular user to the docker group.
As an official configuration? Or in random copy paste guides? The former is very different than the latter. It's not uncommon to disable sudo passwords, but it would be considered a serious security lapse if that were the default on some OS.
You mean the optional post install instructions, which is a separate page from the main install instructions, and contains a giant warning about the security implications?
The methods are described on the official docker website, not just random blogs or SO pages. There are caveats about security, of course, but it's not truly discouraged.
I think there are notes that warn you about the consequences. And they have been written with sys admin in mind which knows about user groups and security.
This also seems like one of the more common things LLMs use to priv escalate themselves when not given root access, seems like a rather common misconfiguration.
Somehow I doubt DHH and company would be OK sacrificing ""developer experience"" for security... There is still a non-trivial amount of docker-compose files and Docker incantations that don't work 1:1 with podman and podman-compose. Adjusting them would require Omarchy's users underatanding podman, and I doubt this will align with the opinionated nature of Omarchy..
Shopify forced him to be a vibe coder now. Omarchy is a vibe coding distribution.
In the AI world, security issues are just another marketing opportunity.
EDIT: Downvote all you want. He was anti-AI, got a board seat at Shopify and then became an AI influencer. Now additional money is rolling in to Omarchy from Lütke and Steinberger.
As I said, podman requires effort and thought on the user's side, as the rootless part incurs complexity. I do not think that this aligns with the omakase mantra of omarchy. I do not think that DHH does not take security seriously. I think that Omarchy is not meant to sacrifice devex for security.
Rootless Podman (and rootless Docker for that matter) is not difficult to set up automatically. There is a little complexity involved, namely in configuring subuid and subgid mappings, but not much.
That said, I think Arch Linux itself has a culture that values the wrong kind of simplicity (implementation simplicity) that perversely leads to a failure to adequately grapple with inherent complexity. This leads to brittle implementations, "buyer beware" norms, "you should have run the notes", "this command should never be used", etc. Omarchy inherits all of that from Arch. It also, it seems, carried its own perverse notion of "simplicity".
because the distro is all about convenience over security, while selling an aura of technical superiority. Which is the modus operandi that worked for the distro author in the past, when he sold VPS with a big markup, because he also gave a script that did "ssh vps -- curl somebashscript" to do basic webdev taks.
> The security tradeoff was made for them, applied to the default account, and the tradeoff was not explained to the user.
just like the vps era. it's all about convenience.
Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works. So this is kind of security theatre. If you run a malicious program it can do stuff like tamper with your PATH or exploit local vulns in apps to get to the point where it can control anything that matters (which root generally doesn't). For instance it can just drop a custom shell into ~/.bin/.hidden-shell and reconfigure the terminal emulator to run it.
So this kind of "vulnerability" doesn't seem that important. If you run code as yourself on Linux it owns you.
On macOS it's very different. Pervasive code signing gives all apps a stable identity enforced by the kernel that they can't easily escape. The kernel can then impose sandboxing policies on any app that's run regardless of how it's installed, for instance, preventing apps from rummaging through ~/Documents or monitoring your screen. Permissions are editable and guaranteed to stick, including across upgrades. And root is disempowered so obtaining it barely matters, it's only really there for UNIX compatibility.
Unfortunately implementing an Apple style architecture on Linux would be very difficult.
> Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works.
I’m sorry, what? MacOS’s desktop sandboxing is pathetic. Sure, it kind of sort of tries to prevent an application from rummaging until you give it permission. And that permission is hilariously coarse grained, and it gets regularly broken anyway. (Seriously, read about TCC breaks. They’re not little implementation errors — they’re giant gaping holes in the whole concept.) The entitlement mechanism basically serves to help Apple restrict what developers can do without meaningful protecting Apple’s users.
If you think that it protects you when your Mac prompts to ask whether Terminal.app may access Documents, you are welcome to enjoy your warm fuzzy feelings.
> Unfortunately implementing an Apple style architecture on Linux would be very difficult.
Why would it be difficult? I think that mostly it would reveal to whomever implemented it how useless it is.
If you mean sandbox-exec, you can do this on Linux, too. And the Linux mechanisms are not considered deprecated and undocumented, whereas Apple steadfastly refuses admit that sandbox-exec is a real mechanism.
There can be exploits in any security system but the architecture is sound. There's no equivalent of TCC on Linux (I mean one that really sticks), and no easy way to create one.
The sandboxing isn't bad. It's obviously weaker if you do everything in the Terminal and stay in old-school UNIX territory because it wasn't designed to sandbox developer workloads. But it's a lot better than nothing, which is what Linux offers.
The OS does actually protect you when it asks if the terminal should be able to access ~/Documents. You can say no, and then random stuff you curl|bash can't read files in that folder unless there's an exploit. Apps that opt in to app sandboxing are much better protected and can store files/settings in an area of $HOME that other apps can't access at all without the right permissions.
It would be difficult to do on Linux because an Apple style architecture requires apps to systematically use the blessed OS APIs for functionality. Not only for things like file pickers but also camera access, storing preferences, etc. In Linux it'd require the architecture to be tied to a specific desktop environment and associated set of apps. There's not enough consistency otherwise.
It also needs pervasive kernel enforced app identity and equivalents to Apple's bookmarks, Mach context propagation, SBPL, app containers architecture etc.
It also needs an agreed on way to handle malware reporting and detection, out of the box, and some authority that's trusted to hand out sensitive permissions (for writing debuggers, if nothing else).
You can hack something together with bits and pieces Linux has, and define a way to write apps that delivers something like Apple's architecture - as Android has - but that won't bring the ecosystem with you. And it will suffer from a high degree of centralization where distributors have to approve every app, with any app you get outside your distro's package repositories being a free for all. Apple's architecture allows apps to be distributed outside the app store while still being sandboxed to a lesser or greater extent, as well as scanned for malware ahead of time.
You need root in order to overwrite sudo in the first place I think, but yes password replay attacks are real. This is why I think it is a good idea to get a yubikey and use PAM to require a physical user presence check to acquire root privileges. You don't even need a password at that point. Unfortunately haven't figured out how to make this work over SSH.
Look at the excerpt. They're not overwriting the sudo binary. The attack vector is real for malware running on a administrator user session which can be escalated to root via sudo.
It's a niche, but it's real. Esp. if you're targeting npm installed user scripts or similar
Any user process can append anything they want to your shell rc (.bashrc, .zshrc). In this case, they added a bash function for a fake sudo prompt. It then uses the password the user entered to run a malicious payload as root.
It’s not, but the grandparent does point out 1 major flaw with sudo being a typically command that goes through normal path discovery. It makes it easier to escalate from a compromised user account to a compromised root account, since the end user is likely to type the root password into a command that can be shadowed in their user space.
Why would you want to make this the default for your users, without even telling them? Did someone configured his own system to work this way and decided it is a good idea to ship it as a part of an "opinionated" distro??? Makes you wonder how much other crap is there.
If you are adding yourself to the docker group, you have presumably read the documentation and its warnings. Does an Omarchy user know the distro has made the decision on their behave?
TFA spells out why this is wrong better than I could.
> There is another important aspect of this configuration. It was opt-out, not opt-in. A user did not have to actually use Docker. The security tradeoff was made for them, applied to the default account, and the tradeoff was not explained to the user.
> Security-sensitive defaults matter precisely because many users reasonably assume that the operating system defaults to secure and will inform or prompt them to opt-in to less secure settings.
I am not disagreeing at all. Nor am I trying to claim this behavior is safe.
I’m just pointing out the level-set that I’m sure the first time someone installs docker and tries to use it, chances are they are just going to install themselves in the docker group without considering the impact and continue on their day.
OK... and? This doesn't matter for a desktop, because:
1. Having access to the user's home directory is way more serious than being able to install drivers or whatever
2. There are a million other ways to escalate to root by obtaining the user's password
I also don't understand the point of these distros, just install Arch with KDE via archinstall, it literally takes 15 minutes. Why is it that people feel the need to use someone's Arch setup?
I just want to put this out there, smolmachines is a wonderful program to solve this, I use this mostly for stuff needing docker socket / docker in docker (example strix and agents). (I'm using podman on my host)
I hate to be defending Omarchy but I think for the modern desktop OS like Linux or Windows or Mac OS, "root" is not what it used to be.
Like if I have something on my dev machines which is important from an enterprise perspective it is the credentials that I use to check things into the git repository or log into the postgresql database that are in some file or keyring or the credentials I used to log into some corporate IT system with my web browser. Or the Microsoft Word document with confidential plans, or the spreadsheet with personal data on 30,000 people that I don't really need to have, etc.
The "root" barrier is of limited effectiveness against those sort of attacks but the barrier between users is less important on a personal computer as opposed to the "minicomputer" world that gave birth to Unix.
In 1989 my school had a cluster of Sun Workstations running Unix for which student, faculty, and staff had accounts and it was a real threat model that you might steal the homework assignment of another student or you might take screenshots of the screen of the computer center's director that would let you watch him reading his email his email and such.
I more concerned that Apache is running under a "httpd" account or IIS is running under its own account so that I do have controls on what can be exfiltrated by that route but...
The modern developer is likely booting up a sinatra or JAXB or a httpx server on some high numbered port running as their own user so if they're going to get hit with data exfiltration or remote execution against a dev server the scope is most user files.
I mean, I saw this on twitter, and thought ok maybe its a nice exploit. But really? its the usual docker root thing?
I wouldn't even consider that a vulnerability tbh, every personal laptop I had I add myself to docker group. Yes, you can not namespace pids, filesystem, etc, and get root, but it's never mattered.
If someone can run that docker command, they can already read your whole homedir, edit bashrc, etc etc,. and sudo is useless anyways.
Only on a system where you are a user without sudo access, does it even begin to make sense. And if you go to the trouble of intentionally setting up a user without sudo access, you wouldn't be adding that user to the docker group.
In the default install, I assume omarchy adds you to the sudoers as well, making this a perfectly ok thing to do
Even if you participate in the esteemed Red Hat Security Theater and use wayland, flatpaks, etc, most flatpaks can write anywhere in your home dir, so they can do this too.
This is the type of security and vulnerability testing that actually matters. In a sea of security researcher noise, thank you for contributing in a meaningful way.
A few days ago someone found they were flowing USB descriptors straight into the shell.
https://github.com/omacom/omarchy/commit/9285b19d6a72eba3df8...
Don't use vibecoded distros. It doesn't matter whether they fix this or that, or whether you care about a particular vuln. This is not sensible. It's why you switched away from Windows in the first place, remember?
the unfortunate thing - is the money pumped into omarchy + the hype around it .... a lot of sheepish followers will just follow the hype.
the tech might gets fixed later.
"Someone" didn't find that, AI found it. So it's not clear what your point is about vibe coding. Would humans have noticed this problem, especially given that it's not remotely exploitable? (you have to plug in a malicious USB device).
Other than hype, what's the appeal here?
I saw a couple video demos recently, and was horrified that it seemed one had to memorize a dozen key binding shortcuts to really use it. Is that rather common now? I'm just a Gnome pleb who prefers discoverability via UI.
Well the whole point is to have a good foundation and then make it actually yours, and the only necessary key binds are probably SUPER+K for the key bind cheatsheet and SUPER+SPACE for the menu.
Also the community is large so there's usually someone that has already had your issue and resolved it. The amount of themes and plugins are growing everyday.
A bare arch+hyprland install really feels terrible to use and has a much larger barrier to entry than Omarchy.
https://plugins.omarchy.org
https://omarchythemes.com
That is the appeal. It's an opinionated distro designed around keyboard navigation.
It's definitely not why *I* switched away from Windows
You didn't switch away from windows to get superior software?
Also, the statement was valid because it will be true for most. It doesn't matter that you read it and it wasn't true for you, as long as it's true by the numbers, it's true, because it's one-to-many communication not one to one.
While I don't want to discuss the quality of any distro vs Windows, there is a big reason most of us use free software: because it is free. Whether for you it is because of free as in freedom or free as in beer specifically, quality may not have much to do with it.
This seems to be quite contrarian considering we had this on the front page of HN the other day: "Debian votes to allow "responsible use of generative AI".
I guess this LLM coding wasn't "Responsible" enough. hahaha
Let the AI bubble pop baby
Omarchy is all in on AI, if you look at the recent commits and the dev workflows they have set up you can easily tell no human is looking at all the stuff they are merging.
It's not the same thing as allowing some AI contributions under strict guidelines.
I think people shouldn't just jump to distros which are getting heavily hyped in media/Youtube, cachyOS had similar wave, and now Omarchy does.
(example: NetworkChuck, Primeagen? and a few others)
also, archlinux is much easier to install nowadays with archinstall [1], so i'm not sure you really need another opinionated layer on top of it
[1] - https://wiki.archlinux.org/title/Archinstall
I think this is more about the UI, rather than the install. I haven't tried it myself though.
I think nowadays using quickshell anyone who is so inclined can vibecode their own UI though. I recently made the switch to Wayland/hyprland and rebuilt my polybar on quickshell, even adding widgets that allow getting system info/fine grained system control (interactive Bluetooth, WiFi, Volume, Brightness etc).
Ah yes, the solution to software with massive security holes is for everyone to vibe code their own software with massive security holes.
But in all seriousness, I am running omarchy now, and I will almost definitely be switching to arch at some point in the future.
Even if you introduce bugs in your UI (which I think is not very likely if you have a basic understanding of your system), the chance that someone would exploit software that literally only runs on your own machine seems extremely unlikely to me.
I've been using arch for over 10 years btw.
Add that annoying theo guy to that list. Cant stand these people, they confidently push out videos like they're experts, a week later it turns out whatever they were talking about was total crap and they've already abandoned it - case in point OpenClaw. Look at the mess of videos those named above put out about it, not a single one uses it anymore.
There is only so much a human can master in his lifetime. And if you choose to master the art of video production, then you are probably not spending that much time on mastering the thing you yap about on camera…
Just use Fedora. It just werks (most times).
I like the very non-windows very non-mac ui of omarchy.
UI is desktop environment and (usually) ports to large-use distros cleanly.
- JaKooLit’s Fedora-Hyprland Repository: https://github.com/JaKooLit/Fedora-Hyprland. The most popular automated setup guide and installer for Fedora, bundling Hyprland alongside pre-configured bars, launchers, and
- Official Hyprland Wiki: wiki.hypr.land/Getting-Started/Installation/. The main reference guide for core configuration options, environment variables, and Wayland portal requirements.
- Solopasha Fedora COPR copr.fedorainfracloud.org/coprs/solopasha/hyprland. The primary community repository hosting cutting-edge builds of Hyprland and its ecosystem packages for
- Fedora Discussion Tutorials: discussion.fedoraproject.org. Community walkthroughs covering minimal netinstall setups and distro-specific Wayland troubleshooting.
Omarchy seems to be pentested by a bunch of angry haters. Who's pentesting your arch install? :P
Basic docker users are the same as angry haters I guess.
"Archlinux is much easier to install nowadays" is not really the point.
Arch is a more general purpose distro. As a developer who mostly wants a Mac-like Linux distro without the associated noise, if you encounter a problem with Arch and ask about it, you will probably get a lot of irrelevant opinions from all sorts of people that run Arch on everything from embedded devices to large servers. In a different way you can see this in this thread where instead of discussing why Omarchy has the bug (guess what, "default user and all processes launched in that user session have access to root." is a convenience that a lot of developers would like to have), people are recommending their favorite distro instead.
Even though I don't like DHH much, what Omarchy is offering is a user experience that is built with a specific sort of developer in mind; the kind that used to use Linux, moved to Macs for the convenience, and would like that convenience replicated on a Linux distro. That's why people use Omarchy specifically rather than Arch, not the YouTube stuff. I think CachyOS was the equivalent for gamers.
> As a developer who mostly wants a Mac-like Linux distro without the associated noise
I'm required to use Ubuntu at work. Coming from Mac, apart from the menu bar at the top, on Gnome, I've been able to customize the keyboard shortcuts, remap the keyboard so that Ctrl works like Cmd, and use extensions like Dash to Dock[1] and themes like Whitesur[2] to replicate something that almost works like a Mac.
The keyboard remapping and customizing keyboard shortcuts were all done within default the default settings app.
The only things missing are some keyboard shortcuts like Ctrl+A/V to move to the beginning and end, and the Ctrl+Shift+C/V behavior on the terminal instead of Cmd+C, which I've just worked around by using VSCode's terminal and configuring it to copy when I press Ctrl+C with some text selected.
[1] https://extensions.gnome.org/extension/307/dash-to-dock/
[2] https://github.com/vinceliuice/WhiteSur-icon-theme
Why doesn't Ubuntu fit the bill? You can even install hombrew on it. Everything works like a mac with no fuss.
Also the only reason I left Linux was due to hardware. Ubuntu was convenient enough.
Homebrew is like giving a bunch of wikipedia randos remote shell access to your computer. There is no enforced code review policy. Any maintainer can make a commit under a pseudonym and merge their own code to main without review.
Homebrew should not be allowed near any machine you need to be able to trust.
> In a different way you can see this in this thread where instead of discussing why Omarchy has the bug
There's nothing interesting to discuss. Rootless OCI-compliant containers exist, and Omarchy ignored them. The "convenience" of the solution they chose simultaneously opens an enormous attack surface that the maintainers didn't consider.
This is why I don't believe the "give me a macOS distro" people - even Apple wouldn't do this. If you want a preconfigured Mac-like distro, then you should use GNOME and not a pre-riced desktop with hundreds of dotfiles. You don't have to use Arch either, you can go with a graphical install of Fedora or CachyOS if you want. This will give you a system that you can understand, maintained by people with a minimum standard of quality, that actually resembles the workflow of macOS. There is no Niri or Sway rice that will magically make your system make sense, and this is why I think a lot of the Mac and Windows expats should just use a normal desktop.
> if you encounter a problem with Arch and ask about it
It's probably already documented on Arch wiki or it's a generic Linux issue that has already been solved by someone (that has been my experience with Cachy).
Omarchy imo is best for agent maxxing Mac power users who aren't locked into Apples proprietary apps like Final Cut, audio production software or Adobe and Affinity, so maybe not so great for designers and photographers as the main system.
It’s not great, but I’m not sure this should be framed as Omarchy-specific, when it’s a very common setup to add regular user to the docker group.
It is one thing to do things the risky way on your own system and another thing to ship an unsafe and unconventional default to your users.
> but I’m not sure this should be framed as Omarchy-specific,
Adding the user to the docker group by default, out of the box, is Omarchy-specific.
EDIT: More accurately, was Omarchy specific, until they realized that it's not a good idea and changed it.
Docker can be run rootless. It is so easy. No excuse for desktop distros to not do this by default. And that is why all major Linux distros are just as bad as Omarchy (Not recommending MacOS or Windows either as those are wildly worse)
>when it’s a very common setup to add regular user to the docker group.
As an official configuration? Or in random copy paste guides? The former is very different than the latter. It's not uncommon to disable sudo passwords, but it would be considered a serious security lapse if that were the default on some OS.
Adding your user to the docker group is in the official Docker install instructions, I wouldn't call that "random copy paste guides".
You mean the optional post install instructions, which is a separate page from the main install instructions, and contains a giant warning about the security implications?
https://docs.docker.com/engine/install/linux-postinstall
If the official sudo project had a guide on how to disable passwords, that shouldn't be taken as endorsement of having that as a default config.
The methods are described on the official docker website, not just random blogs or SO pages. There are caveats about security, of course, but it's not truly discouraged.
I think there are notes that warn you about the consequences. And they have been written with sys admin in mind which knows about user groups and security.
You mean, just how it is on Windows?
Using Docker instead of podman is the first mistake and that is a distro decision (or a "chef" decision, in Omarchy parlance...)
This also seems like one of the more common things LLMs use to priv escalate themselves when not given root access, seems like a rather common misconfiguration.
I had no idea what Omarchy was, so I looked it up: https://omarchy.org/
Is there a name for a phobia of yt thumbnails?
Why not use rootless podman? It is 2026 not 2016, Podman works much better than Docker today.
The article specifically calls this out as a preferred option.
that's what I do and what the author recommends as well
Somehow I doubt DHH and company would be OK sacrificing ""developer experience"" for security... There is still a non-trivial amount of docker-compose files and Docker incantations that don't work 1:1 with podman and podman-compose. Adjusting them would require Omarchy's users underatanding podman, and I doubt this will align with the opinionated nature of Omarchy..
Omarchy is an agent first experience, no? just ask your agent!
Come on. I am sure you don’t like DHH. But he’s always taken security seriously in Rails.
Shopify forced him to be a vibe coder now. Omarchy is a vibe coding distribution.
In the AI world, security issues are just another marketing opportunity.
EDIT: Downvote all you want. He was anti-AI, got a board seat at Shopify and then became an AI influencer. Now additional money is rolling in to Omarchy from Lütke and Steinberger.
As I said, podman requires effort and thought on the user's side, as the rootless part incurs complexity. I do not think that this aligns with the omakase mantra of omarchy. I do not think that DHH does not take security seriously. I think that Omarchy is not meant to sacrifice devex for security.
Rootless Podman (and rootless Docker for that matter) is not difficult to set up automatically. There is a little complexity involved, namely in configuring subuid and subgid mappings, but not much.
That said, I think Arch Linux itself has a culture that values the wrong kind of simplicity (implementation simplicity) that perversely leads to a failure to adequately grapple with inherent complexity. This leads to brittle implementations, "buyer beware" norms, "you should have run the notes", "this command should never be used", etc. Omarchy inherits all of that from Arch. It also, it seems, carried its own perverse notion of "simplicity".
because the distro is all about convenience over security, while selling an aura of technical superiority. Which is the modus operandi that worked for the distro author in the past, when he sold VPS with a big markup, because he also gave a script that did "ssh vps -- curl somebashscript" to do basic webdev taks.
> The security tradeoff was made for them, applied to the default account, and the tradeoff was not explained to the user.
just like the vps era. it's all about convenience.
Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works. So this is kind of security theatre. If you run a malicious program it can do stuff like tamper with your PATH or exploit local vulns in apps to get to the point where it can control anything that matters (which root generally doesn't). For instance it can just drop a custom shell into ~/.bin/.hidden-shell and reconfigure the terminal emulator to run it.
So this kind of "vulnerability" doesn't seem that important. If you run code as yourself on Linux it owns you.
On macOS it's very different. Pervasive code signing gives all apps a stable identity enforced by the kernel that they can't easily escape. The kernel can then impose sandboxing policies on any app that's run regardless of how it's installed, for instance, preventing apps from rummaging through ~/Documents or monitoring your screen. Permissions are editable and guaranteed to stick, including across upgrades. And root is disempowered so obtaining it barely matters, it's only really there for UNIX compatibility.
Unfortunately implementing an Apple style architecture on Linux would be very difficult.
> Unfortunately implementing an Apple style architecture on Linux would be very difficult.
On desktop Linux as we know it, yes, but Android manages it alright, mostly via SELinux+seccomp.
Android is basically a different OS that happens to reuse parts of the Linux kernel.
> it doesn't have any kind of proper desktop sandboxing architecture that really works.
Bubblewrap works.
and Firejail
> Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works.
I’m sorry, what? MacOS’s desktop sandboxing is pathetic. Sure, it kind of sort of tries to prevent an application from rummaging until you give it permission. And that permission is hilariously coarse grained, and it gets regularly broken anyway. (Seriously, read about TCC breaks. They’re not little implementation errors — they’re giant gaping holes in the whole concept.) The entitlement mechanism basically serves to help Apple restrict what developers can do without meaningful protecting Apple’s users.
If you think that it protects you when your Mac prompts to ask whether Terminal.app may access Documents, you are welcome to enjoy your warm fuzzy feelings.
> Unfortunately implementing an Apple style architecture on Linux would be very difficult.
Why would it be difficult? I think that mostly it would reveal to whomever implemented it how useless it is.
If you mean sandbox-exec, you can do this on Linux, too. And the Linux mechanisms are not considered deprecated and undocumented, whereas Apple steadfastly refuses admit that sandbox-exec is a real mechanism.
There can be exploits in any security system but the architecture is sound. There's no equivalent of TCC on Linux (I mean one that really sticks), and no easy way to create one.
The sandboxing isn't bad. It's obviously weaker if you do everything in the Terminal and stay in old-school UNIX territory because it wasn't designed to sandbox developer workloads. But it's a lot better than nothing, which is what Linux offers.
The OS does actually protect you when it asks if the terminal should be able to access ~/Documents. You can say no, and then random stuff you curl|bash can't read files in that folder unless there's an exploit. Apps that opt in to app sandboxing are much better protected and can store files/settings in an area of $HOME that other apps can't access at all without the right permissions.
It would be difficult to do on Linux because an Apple style architecture requires apps to systematically use the blessed OS APIs for functionality. Not only for things like file pickers but also camera access, storing preferences, etc. In Linux it'd require the architecture to be tied to a specific desktop environment and associated set of apps. There's not enough consistency otherwise.
It also needs pervasive kernel enforced app identity and equivalents to Apple's bookmarks, Mach context propagation, SBPL, app containers architecture etc.
It also needs an agreed on way to handle malware reporting and detection, out of the box, and some authority that's trusted to hand out sensitive permissions (for writing debuggers, if nothing else).
You can hack something together with bits and pieces Linux has, and define a way to write apps that delivers something like Apple's architecture - as Android has - but that won't bring the ecosystem with you. And it will suffer from a high degree of centralization where distributors have to approve every app, with any app you get outside your distro's package repositories being a free for all. Apple's architecture allows apps to be distributed outside the app store while still being sandboxed to a lesser or greater extent, as well as scanned for malware ahead of time.
Installing docker by default is completely insane. What are they doing? Rootless podman has been around for many years at this point.
To be fair it is easy for malware to escalate to root on any major linux distro because sudo is completely security theater.
Just overwrite sudo with this evil sudo:
function sudo () {
Wow. This never crossed my mind but of course that's so simple. There really needs to be a better solution.
Indeed, and most flatpaks have access to the home directory so are also able to do this even though they're """sandboxed"""
You need root in order to overwrite sudo in the first place I think, but yes password replay attacks are real. This is why I think it is a good idea to get a yubikey and use PAM to require a physical user presence check to acquire root privileges. You don't even need a password at that point. Unfortunately haven't figured out how to make this work over SSH.
> You need root in order to overwrite sudo in the first place I think
You just need write access to .bashrc or similar.
Look at the excerpt. They're not overwriting the sudo binary. The attack vector is real for malware running on a administrator user session which can be escalated to root via sudo.
It's a niche, but it's real. Esp. if you're targeting npm installed user scripts or similar
No, the above attack writes that function into bashrc, meaning the next time the user runs sudo themselves, you harvest their password.
What? Why is sudo security theater?
Any user process can append anything they want to your shell rc (.bashrc, .zshrc). In this case, they added a bash function for a fake sudo prompt. It then uses the password the user entered to run a malicious payload as root.
It’s not, but the grandparent does point out 1 major flaw with sudo being a typically command that goes through normal path discovery. It makes it easier to escalate from a compromised user account to a compromised root account, since the end user is likely to type the root password into a command that can be shadowed in their user space.
Because it is trivial for unprivileged malware to phish the password and escalate to root. No production system should ever ship with sudo.
script kiddie "distribution".
Debian 13 is good.
Surprised by this. I only ever use podman these days and haven’t felt the need for docker. Feels like reading about a CVE in Compiz.
I was expecting a more sophisticated attack and then I scrolled down…
> Omarchy configured its default user as a member of the Linux docker group.
What the fuck? Docker makes it VERY, VERY clear this is unsafe. Feel free to verify the documentation.
https://docs.docker.com/engine/install/linux-postinstall/
Why would you want to make this the default for your users, without even telling them? Did someone configured his own system to work this way and decided it is a good idea to ship it as a part of an "opinionated" distro??? Makes you wonder how much other crap is there.
> Did someone configured his own system to work this way and decided it is a good idea to ship it as a part of an "opinionated" distro???
Isn't that the entire selling point of Omarchy?
Default configuration or not, I also imagine the first thing people using docker do is to add themselves to the docker group via sudo.
If you are security-conscious, you shouldn’t be using docker anyway.
If you are adding yourself to the docker group, you have presumably read the documentation and its warnings. Does an Omarchy user know the distro has made the decision on their behave?
TFA spells out why this is wrong better than I could.
> There is another important aspect of this configuration. It was opt-out, not opt-in. A user did not have to actually use Docker. The security tradeoff was made for them, applied to the default account, and the tradeoff was not explained to the user.
> Security-sensitive defaults matter precisely because many users reasonably assume that the operating system defaults to secure and will inform or prompt them to opt-in to less secure settings.
I am not disagreeing at all. Nor am I trying to claim this behavior is safe.
I’m just pointing out the level-set that I’m sure the first time someone installs docker and tries to use it, chances are they are just going to install themselves in the docker group without considering the impact and continue on their day.
I have passwordless sudo anyway. XKCD knows why the password is pointless.
> Why would you want to make this the default for your users
Because DHH doesn't have a clue what he's doing and is farming his brain out to Claude. Again.
Because it's convenient, and the security of this doesn't matter for desktop usage.
lol. people will vote you and not realize the irony.
just look at all the comments "this is a fair and common mistake" that are not being ironic.
Somebody should do an audit of Omarchy Plugins: https://plugins.omarchy.org/
They run completely unsandboxed and are unvetted.
As expected from a vibecoded "distro"
What on earth is an Omarchy
Officially omakase (clueless chef decides your menu with security issues) and arch linux.
The fact that it is almost an anagram of monarchy is probably a plus for DHH.
You realize you are exemplary hater when you feel an urge to post comments like this
OK... and? This doesn't matter for a desktop, because:
1. Having access to the user's home directory is way more serious than being able to install drivers or whatever
2. There are a million other ways to escalate to root by obtaining the user's password
I also don't understand the point of these distros, just install Arch with KDE via archinstall, it literally takes 15 minutes. Why is it that people feel the need to use someone's Arch setup?
Because they like their Arch setup? Because installing Omarchy is three to five minutes at most so three to five times faster? XD
Because it looks cool and DHH makes a lot noises that sounds like you should listen to him.
And he politically aligns with a lot of people.
https://xkcd.com/1200/
Is it not better to run a VM just for Docker, like we have to do on macOS?
That has all sorts of issues like eating disk space and RAM, because neither can't be released to the host once allocated, but then become unused.
At least is secure(tm)
I just want to put this out there, smolmachines is a wonderful program to solve this, I use this mostly for stuff needing docker socket / docker in docker (example strix and agents). (I'm using podman on my host)
At that point why not just simplify things and go back to Vagrant...?
Damn, I did not know you need a VM for Docker on macOS. That's kind of ironic, isn't it XD
Every day I wake up and thank the universe for MS making WSL2
WSL2 is also a virtual machine.
WSL2 is also a VM. docker relies on the linux kernel apis, so it must be ran inside a linux VM on macos or windows
Windows does have a native sandboxing API that Docker is capable of using IIRC, but nobody uses it.
The macOS situation is even worse in that the kernel lacks the requisite capabilities.
I’d rather run real Linux in a VM than a buggy appropriation of it in WSL
Isn’t WSL2 vm based?
I hate to be defending Omarchy but I think for the modern desktop OS like Linux or Windows or Mac OS, "root" is not what it used to be.
Like if I have something on my dev machines which is important from an enterprise perspective it is the credentials that I use to check things into the git repository or log into the postgresql database that are in some file or keyring or the credentials I used to log into some corporate IT system with my web browser. Or the Microsoft Word document with confidential plans, or the spreadsheet with personal data on 30,000 people that I don't really need to have, etc.
The "root" barrier is of limited effectiveness against those sort of attacks but the barrier between users is less important on a personal computer as opposed to the "minicomputer" world that gave birth to Unix.
In 1989 my school had a cluster of Sun Workstations running Unix for which student, faculty, and staff had accounts and it was a real threat model that you might steal the homework assignment of another student or you might take screenshots of the screen of the computer center's director that would let you watch him reading his email his email and such.
I more concerned that Apache is running under a "httpd" account or IIS is running under its own account so that I do have controls on what can be exfiltrated by that route but...
The modern developer is likely booting up a sinatra or JAXB or a httpx server on some high numbered port running as their own user so if they're going to get hit with data exfiltration or remote execution against a dev server the scope is most user files.
10M for a some shell scripts what a steal lmao
Lol. This misconfiguration is so common and so trivial that LLMs have been known to exploit it unprompted, to complete their task.
I mean, I saw this on twitter, and thought ok maybe its a nice exploit. But really? its the usual docker root thing?
I wouldn't even consider that a vulnerability tbh, every personal laptop I had I add myself to docker group. Yes, you can not namespace pids, filesystem, etc, and get root, but it's never mattered.
If someone can run that docker command, they can already read your whole homedir, edit bashrc, etc etc,. and sudo is useless anyways.
Only on a system where you are a user without sudo access, does it even begin to make sense. And if you go to the trouble of intentionally setting up a user without sudo access, you wouldn't be adding that user to the docker group.
In the default install, I assume omarchy adds you to the sudoers as well, making this a perfectly ok thing to do
Even if you participate in the esteemed Red Hat Security Theater and use wayland, flatpaks, etc, most flatpaks can write anywhere in your home dir, so they can do this too.
[I don't use omarchy]
This is the type of security and vulnerability testing that actually matters. In a sea of security researcher noise, thank you for contributing in a meaningful way.