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.
I’m not on the systemd hate train by any means, but I don’t understand how this is any improvement over
pkexecThat has the same problem as
sudo: the SUID bit is set for it.The fact that
run0uses 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 cansystemctl status, butsystemctl rebootneeds to be in thewheelgroup) 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.I’m unclear from the documentation, does pkexec work under non-GUI contexts?
As long as you have polkit setup to work in terminal sessions, yes. This is pretty standard these days, though not particularly widely used.