Omarchy: Any User Process Can Escalate to Root

You may do that, but I don't. I always use sudo to manage the few docker containers I need, and I prefer podman where possible specifically because I can run it rootless.

If you want to give your user passwordless root for convenience, go ahead, but that should never be the default.

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.

I didn't know this.

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

The problem I've always had with trying out a tiling window manager like hyprland is you're going to spend a very long time trying to get everything just right. With Omarchy I get a really nice hyprland setup right out of the box.

Omarchy aims to find a middle ground between those two.

I should have gone with something like cachyos as games are important to me, but I think at the time hyperland wasn't an option (i don't remember). I know it is now.

Whoa! You have to _learn_ something to use it well? Yikes. Not for me.

It was already hard to have technical conversations in public, now there is a contingent determined to make it utterly impossible, and they are succeeding.

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.

It's not the same thing as allowing some AI contributions under strict guidelines.

But in all seriousness, I am running omarchy now, and I will almost definitely be switching to arch at some point in the future.

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 and located anywhere on disk (by extension, you can have >1 version of an app installed at once and sandboxing still works).

I was also unable to find any Flatpak that has access to the home directory when installed, you may well be right but I couldn't find any. I used Flatseal to verify the permissions: https://flathub.org/en/apps/com.github.tchx84.Flatseal

I'm also of the opinion that we generally shouldn't use software that we don't absolutely trust. That has kept my .bashrc (and other files) safe so far.

You just need write access to .bashrc or similar.

> 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.

Unprivileged malware will be waiting with a root payload ready to fire the next time you tap your yubikey.

It's a niche, but it's real. Esp. if you're targeting npm installed user scripts or similar

They didn't say anything about overwriting the sudo binary, and that is not required, which I think was their whole point was to show exactly how that is not required.

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.

just look at all the comments "this is a fair and common mistake" that are not being ironic.