(I'll attempt this based on my understanding of both)

Pouring a cup of juice is something an adult needs to be involved with.

sudo is when you ask for permission to pour your own cup of juice. You ask an adult, they give you the cup and the juice, and then you're responsible for pouring it. If the adult isn't paying attention they may leave the fridge open for you to go back for more juice or another beverage, but otherwise you're limited to the amount of juice the adult has given you.

run0 is when the adult just gets you a cup of juice. You tell them what you want, they go and pour the juice, and just give you the cup with the juice in it. You never enter the kitchen, so you don't have access to the fridge, just your cup of juice.

Some executables are special. When you run them, they automagically run as root instead! But if sudo isn't very, very careful, you can trick it into letting you run things as root that you shouldn't be able to.

Run0 DM's systemd asking it to go fork a process as root for you, and serves as the middleman between you and the other process.

You had me rolling, bud.

I haven't had D-Bus problems in quite a while but actually run0 should help with some of those issues. Like, systemctl --user will actually work when used with run0, or at least systemd-run can.

Haven't used it yet so it's all theoretical, but it makes sense to me especially at work. I've used systemd-run to run processes in very precise contexts, it's worth using even if just to smush together schedtool, numactl, nice, taskset and sudo in one command and one syntax. Anything a systemd unit can do, systemd-run and run0 can do as well.

I'm definitely going to keep su around just in case because I will break it the same I've broken sudo a few times, but I might give it a shot and see if it's any good just for funsies.

Just trying to explain what it does and what it can do as accurately as possible, because out of context "systemd adds sudo clone" people immediately jump to conclusions. It might not be the best idea in the end but it's also worth exploring.

At that point just set a break-glass root password and don’t use sudo or doas.

Some people are opposed to sudo being a fairly complex program with an awkward to understand configuration language and a couple of methods that can fetch config from elsewhere. Fixing upstream sudo can't happen because those features exist and are presumably used by some subset of people, so straight up removing them is not good, but luckily doas and sudo-rs exist as alternatives with a somewhat stripped featureset and less footguns.

Others are opposed to the concept of SUID. Underneath all the SUID stuff lies far more complexity than is obvious at first sight. There's a pretty decent chunk of code in glibc's libdl that will treat all kinds of environment variables differently based on whether an executable is SUID, and when that goes wrong, it's reported as a glibc bug (last year's glibc CVE-2023-4911 was this). And that gets all the more weird when fancy Linux features like namespaces get involved.

Removing SUID requires an entirely different implementation and the service manager is the logical place for that. That's not just Lennart's idea; s6, as minimal and straight to the point as it tends to be, also implements s6-sudo{,d,c}. It's a bit more awkward to use but is a perfectly "Unix philosophy" style implementation of this very same idea.

Or just use doas, it's still more secure than sudo