This just sounds like a bad idea, a solution in search of a problem. Sure, sudo is a setuid binary, but it’s a fairly simple program, and at some point, you have to trust the code. It’s also a very fundamental piece of the system that you want to always work, even (especially!) when other things get borked. The brief description of run0 already has too many potential points of failure.

sudo is a setuid binary, but it’s a fairly simple program

Some people would disagree to this.

The brief description of run0 already has too many potential points of failure.

If the “listener” is PID1, which will run the privileged command, in theory, it would be quite bullet proof (in a working system PID1 is always there). But since this is systemd, PID1 is much more than that and much more complex. On the other hand spawning another daemon from PID1 to be the “listener” makes it, perhaps, even more complicated. You’d have to make sure the listener is always running and have some process supervisor there to watch if it exits… and maybe even a watchdog polling it to make sure it isn’t frozen.

So my conclusion is the same as yours:

a solution in search of a problem

We already have a working solution. Have a well written SUID program. I’ve been using doas for some years now. It’s simple enough that I trust it.

I’ve always wondered why we even bother with SUID commands. Why not just log in as root?

sudo and friends allow you to gain root access while not enabling the root account. If the root account has no credentials then nobody is guessing your password and logging in as an admin.

On a multi-user system it allows for multiple admins without sharing a password. It also allows providing admin access for “some” things but not others.

If the root account has no credentials then nobody is guessing your password and logging in as an admin.

They just need to log in as you and trick you into entering your password in a seemingly legit prompt.

On a multi-user system it allows for multiple admins without sharing a password.

Multiple distinct ssh keys do the same. As long as everybody ends up doing things as the same user it’s all moot anyway.

It also allows providing admin access for “some” things but not others.

Can I provide selective access to just some files? Just some network interfaces? Just some ports? Just some parts of RAM or CPU? Without being able to change those limits?

So just login as root to your system then. You’ll be fine.