I’m unclear from the documentation, does pkexec work under non-GUI contexts?

I don’t understand how this is any improvement over pkexec

That has the same problem as sudo: the SUID bit is set for it.

The fact that run0 uses polkit is more of a byproduct that this kinda authentication is already done with polkit all over the place in systemd. You can have individual subcommand accessible to different users (for example everyone can systemctl status, but systemctl reboot needs to be in the wheel group) which is why its generally used within systemd already. And it wouldn’t surprise me if again you can do it with this as well, limiting what commands can unconditionally run, need prompt or are completely blocked.

You know what’s nice? Being able to sit down at any Linux distro and being able to set up and configure services without Googling how to use that particular distro’s init system.

Those hacked together system-specific bash scripts were shit. Having a standard way of creating, starting, ensuring restarts,and logging services is so much better.

You can still get all the plain text logs you like.

Lmao yeah exactly

The thing with this is: its just a symlink to the systemd-run binary, which talks to PID1 to spawn new processes (in separate cgroups IIRC). Its one of the most fundamental parts of systemd. Even the debian systemd package includes systemd-run.

I guess the other question is if some tools the distro provides might switch to supporting it by default. For example on Arch there is makepkg that should never be executed as root, but does internally call some things with elevated privileges (mostly pacman to install and remove packages). Currently it checks for sudo and if not falls back to su, but maybe it might be worth considering changing su for run0 if its guaranteed to be there.

doas is quite popular in the BSD world, and was ported to Linux a few years ago (via the OpenDoas project).

For starters, it’s is a lot smaller than sudo - under 2k lines of code vs sudo’s 132k - this makes it lot more easier to audit and maintain, and technically less likely to have vulnerabilities.

Another security advantage is that doas doesn’t pass on the environment variables by default (you’d have to explicitly declare the ones you want to pass, which you can do so in the config).

The config is also a lot simpler, and doesn’t force you to use visudo - which never made sense to me, visudo should’ve just generated the actual config, instead of checking it after the fact. Kinda like how grubby or grub2-mkconfig works. But no need for that complexity with doas.

Eg, the most basic doas config could just have one line in the file: permit: wheel. Maybe have another line for programs you want to run without a password, like permit nopass dexter cmd pacman.

Essentially functionally stripped sudo, smaller in size than sudo. See also Pottering’s thoughts about the ecosystem

Thanks for taking the time to explain. I was trying to get my head around on how this works but could not understand much of it. A lot of people here are very much against systemd in all senses, but this sounds like a better approach. Even if it not done as systemd, makes more sense than checking files and getting elevated privileges for a scope and use guardrails everywhere

You’d be wrong about that.

Edit: he just downvotes me instead of admitting he’s wrong about his assumption, lol.

Actually no. The thing is just that systemd handles so many things that makes the lives both developers/distro maintainers and users easier, but most of it happens in the background. You can forget about having to learning complexer tools, just do it all via systemd

Why do you consider it as poisoning? I’ve heard the argument about not doing things the traditional Linux way (binary logs for example). But if the alternative provides so many benefits, why is it an issue? Systemd is a piece of cake for all parties compared to sysvinit and alternatives, so why is it bad when it solves so many issued, and makes it super easy to use by just adding e.g. a new option to a Unit?

Another example: timers are more complex than cronjobs, but timers offer additional needed features like dependencies, persistence, easy and understandable syntax, and more. So although more complex, once you get the hang of them, they’re a very welcomed feature imo

The guy who discovered the xz attack was also a Microsoft employee, for what it’s worth.

Most of systemd stuff is decoupled well. You don’t need to use networkd to make use of resolved for example.