Should I be using run0 instead of sudo?

When gparted is executed as a normal user it asks for the password. My sudo is not asking for a password. I have NOPASSWD for all commands, which is not possible with run0. I sometimes even open a separate terminal window just for the root user (ptyxis, etc.).

I am going with this use case since 30 years now. I am fine with.

I was only commenting why I will not switch to run0 unless it

  • allows NOPASSWD
  • allows DISPLAY access

I concur. I wish there was ā€œLIKEā€ option. Debian Forums have a Best Threads option. This collates all the most interesting and awesome threads together, weekly. Would love to have something similar over here.
Maybe a enhancement request for mods.

2 Likes

It is surprising that EOS has both of these installed along with sudo and run0. I wonder why is it. I had assumed that having sudo or doas was sufficient. No need for pkexec and runuser.

So for your specific use case user0 is not suitable.

Fine.

There is no on-size-fits-all in using Linux.

They are from dependencies of needed packages, for example pkexec:

LANG=C pacman -Qii $(pacman -Qo pkexec | awk '{print $5}') | grep "Required By"
4 Likes

This one was new to me. Now I see it is part of util-linux with a whole lot of other everyday goodies.

run0 is part of systemd. You can’t really not install it.

The same is true of pkexec is part of polkit. Additionally, pkexec is used by many applications. Lots of things would stop working properly if you removed it.

3 Likes

run0 is meant to be more secure than sudo. I think it is fair to say you are not the target audience. :sweat_smile:

If you use sudo with no password or leave a root terminal open, anyone who gains access to your system immediately has root access. run0 cannot save you if those are your requirements. That would be like shopping for a more secure lock for the front door, but then always keeping the door propped wide open.

You can preserve needed environment variables with the setenv flag. Note you likely had to do this with sudo as well, by setting a Defaults env_keep += line in your sudoers config.

4 Likes

This is a general problem and not sudo specific. You can run a root shell in a terminal with ā€œrun0 zshā€ and leave it open.You can start gparted as a normal user, authenticate and then leave that window open. The solution is a screen lock when you leave the computer. That is best practice and eliminates this problem reliably.

I only have this in /etc/sudoers: Defaults env_keep += "TERM TERMINFO". By the way, kdesu on plasma does the same thing. e.g. kdesu dolphin opens a filemanager as root user. That can be convenient for certain maintenance tasks.

No, it is not really a ā€œgeneralā€ problem, nor a problem specific to sudo or run0 or anything else…more of a workflow problem.

My point was not that run0 prevents you from making your setup insecure, but rather just to raise the question: if you are making your system insecure on purpose like this, then what benefit are you actually hoping to get from run0? It is probably just not a useful tool in your case.

No, if someone gains remote access to your computer a screen lock will not deter them in any way. In your case they will immediately gain root access.

5 Likes

Thats_A_Fact1

2 Likes

Yeah, I said that… but my size fits the best :rofl:

3 Likes

Having spent many years in Cyber Security, root access has been somewhat of a trigger for me. One of my first triumphs was convincing (almost everyone, there was that one guy) that sudo access was sufficient w/o walking around carrying a physical list of root passwords for the systems in our data center.

4 Likes

I have created a new thread about the sudo NOPASSWD / GUI topic because I do not want to hijack this thread here.

Please share your opinion on the topic here:

4 Likes

So in that case what is the alternative for sudo that you ended up using? Use pkexec or doas or something else?

run0 when sudo fails/failed to authenticate, or ā€˜su - root’ in a terminal

So the following are the tools for getting elevated privileges

  1. sudo - The default but is frowned upon by many as it increases the attack surface area.
  2. doas - a substitute for sudo with the same principles. Is supposed to have a smaller attack surface.
  3. run0 - An alternative provided by systemd which works on the principle of transient services. Fresh bloke.
  4. runuser - Cannot be used to elevate privileges to root. But useful for executing programs/scripts as other users.
  5. pkexec - Based on policy toolkit. Cannot be removed from the system. Many things will fail.

In addition there are GUI counterparts to these terminal commands like kdesu and kdesudo. Which have the same limitation as sudo and su and even more frowned upon.

If someone wants to stop a user from getting elevated privileges or create a guest account or create a restricted account then they need a mechanism to stop all of these methods.

This thread is turning out to be a gold mine. It needs to be made into a sticky thread. Any idea how that can be achieved?

2 Likes

run0 I can understand. But using su - in the terminal? Isnt that as bad as using sudo itself ? If the aim is to avoid or stop using sudo then why permit su -?

I don’t believe anyone said sudo was bad (though I did say it’s maybe not as well maintained as it used to be).

The same can be said for doas too. The last update on the project happened in 15-Feb-2024. While OpenDoas the fork of doas into linux had its last release in Jan-2022. On the other hand sudo had its latest release in Nov-2024 and has been keeping a pretty good release schedule.

I am not questioning or putting into doubt the claim that sudo does have issues. Neither am I saying that it is not correct to restrict the usage of sudo. I agree with that. I just want to know why is sudo considered bad when it has been regularly updated? What am I missing? Is there some issue with the sudo architecture or the way sudo has been implemented that is the cause? Or is there something else?

Please do not take this post in any other way. Just want to know.