run0 may be used to temporarily and interactively acquire elevated or different privileges. It serves a similar
purpose as sudo(8), but operates differently in a couple of key areas:
• No execution or security context credentials are inherited from the caller into the invoked commands, as
they are invoked from a fresh, isolated service forked off by the service manager.
• Authentication takes place via polkit[1], thus isolating the authentication prompt from the terminal (if
possible).
• An independent pseudo-tty is allocated for the invoked command, detaching its lifecycle and isolating it
for security.
• No SetUID/SetGID file access bit functionality is used for the implementation.
Altogether this should provide a safer and more robust alternative to the sudo mechanism, in particular in OS environments where SetUID/SetGID support is not available (for example by setting the NoNewPrivileges= variable
in systemd-system.conf(5)).
Does Archlinux set the NoNewPrivileges= variable? Should I be using run0 going forward? Any disadvantages, negative side-effects? Does some of you use it already instead of sudo?
I honestly don’t know what to make of run0. I’m not even sure what it’s supposed to do. I’ve found articles here and there. But, still… between general sudo usage, yay and sudo pacman, I’m good for now.
And this seems quite vague and needlessly complicated at the same time. Particularly for a newer user to Linux.
Yes, I am glad because on my previous (or maybe 2 back?) install sudo would occassionally and (as far as I could tell) unpredictably stop authenticating correctly. It was nice to have another setuid program to fall back on, even though ‘su - root’ still worked too, even if it’s (run0) yet another roach in the systemd tree lol.
I contributed code to sudo a couple of times, but when I stop and consider how long ago THAT was (1997 era I think), it’s probably getting a bit long in the tooth and doesn’t seem as well maintained as it was back then. I may be wrong in my assessment, but that’s how I feel about things at the moment
I also know sudo (which was originally a BSD thing as I recall), is now being replaced in BSD land with runas.
So there is now sudo, doas and run0/systemd-run. There ought to be a comparison table between these tools.
Also after reading the documentation it appears that run0 executes elevated privileges as a transient service. And there are some good options available with it like --property=ProtectSystem=strict
this helps in avoiding any damage to the file systems.
From the manual
One point is not clarified. users who can run sudo can be controlled by /etc/sudoers file or by adding the user to the wheel/sudo group. There is no way to control something similar for run0 command.
I tried it when it was first available. I wasn’t impressed and forgot all about it until I read this thread. I will still use sudo as it’s an old habit.
--setenv=NAME[=VALUE]
Runs the invoked session with the specified environment variable set. This parameter may be used more than once to set multiple variables. When “=” and VALUE are omitted, the value of the variable with the same name in the invoking environment will be used.
Without the =VALUE argument it just preserves whatever the variable is set to in the user’s environment.
run0 --setenv=SOME_VARIABLE some_command
sudo -E passes the entire user environment to root, and really should not be used outside of testing or debugging issues.
I wish the forum offered a “LIKE” to fascinating threads, so I could tag it as awesome…
I ran a distro with doas (Alpine). Loved the distro but did not like doas. Sudo, I guess, is what @SudoMason “big, mature” and I had a comfort zone with it.
Using doas to me was not intuitive or natural so at least I could install sudo later.
Alpine (they didn’t have a DE I liked) was a very secure distro. True, doas has a small attack area. (Just for kicks Alpine’s programs were all in MUSL) so together. Alpine one of the most secure distros out there…except its a Linux world where Glibc rules and MUSL a small minority----but I digress into off-topic, so will stop here.
Why would you need a root shell for launching Gparted? I think it uses pkexec and I just click its icon to get a dialogue box where I put in my user password.
For text editing, I use a terminal based editor, nano, which works fine with run0. I know mousepad can be launched with pkexec if someone ever need to run a graphic text editor with elevated privilege. Perhaps gedit can too. I hve not tried.
Also, Archwiki clearly advises against running GUI application as root.
Maybe you don’t. The point is that it is totally unnecessary when it already launches with pkexec which is a safer way of launching a GUI application with elevated privilege.
