Sudo This is just for FYI not intended to be a troll

Here is one man’s thoughts on sudo vs doas that I found interesting. Thought I would share.



Hmmmmm—and I just saw this today: Makes me think… :slight_smile:

Another alternative (that you could alias as required) is to make use of the su-c_wrapper that eos (thankfully) includes (and thanks @manuel). This works a LITTLE differently - as its name implies it instead wraps around su, and makes it convenient to use, adding in such refinements as “three strikes and you’re out” for password retries etc. Another difference is that it doesn’t ‘keep open’ the root access for (usually 15 min) a while the way sudo does. It could mean entering your password a bit more often - or it could just mean less potential vulnerability.

I have been using it in specific aliases for a while (such as update), as I prefer certain things to need the root password rather than the user password - if only to make sure I’m thinking about what I’m doing on those commands! It can be almost a reflex to fire off your user password on request, with possibly unintended consequences!

So - make the choice that suits you, but hopefully you now know more about what the (convenient) choices are…

Arch is on sudo 1.9.5.p2-1 which is not affected.

1 Like

I quickly tested doas. It does not handle the DISPLAY.

I can open a terminal app as root with sudo xfce4-terminal but I can not do that with doas. What a pity.

Some sudo info:

What really counts is this one:

I’m necro’ing the hell out of this but i’m interested in replacing sudo for my desktop to minimise the attack surface.

I’ve got 3 questions for current doasers:

1- What are the ramifications of doing this ? I guess custom endeavour os applications rely on sudo, if i make “sudo” as an alias for doas would that solve it ? This is doubly important as i don’t have a seperate root user.

2- There’s opendoas-sudo package in aur with the description “a symlink for using doas as a drop-in replacement to sudo”, should I use this instead of an alias ?

3- At the moment there are many doas aur packages, which one should I use ? opendoas 6.8.1-3, doas 6.3p2-4, opendoas-git

I don’t currently use doas but I don’t think this would be reliable unless you can guarantee that every process which relies on sudo would:

  1. source your profile/rc file
  2. Not call /usr/bin/sudo or /bin/sudo

Yes, this would solve the problems mentioned above.

@Bancerk , As a side note, if you are trying to reduce your attack surface, couldn’t you just use pkexec which you likely already have installed?

It kind of sucks that a package would have a hard dependency on sudo. Which packages have that dependency?

1 Like

I use sudo only sometimes, as I prefer to have to think about what I am doing… :grin: In my case, I have different passwords for root and user, and if the command is ‘important’ (like updates), I like to have to enter the root pwd to initiate it.

I do this by making use of the nifty little su-c_wrapper hiding in /usr/bin, which gives three-try functionality to su. It is a script - (thanks @manuel) so have a look to see if helps you too… although differently!

1 Like

@dalto @freebird54 Thank you both for your shared wisdom.

I came across the youtube video on the first post some time ago and the recent bug found (and patched) on sudo made me a little paranoid even though only achievable by having physical access to the machine. I’ve only been using linux for a year at most so I’m not very well versed in how things work.

Basicly what I’m trying to do is to not have root account active at all and substitute that with doas as opposed to sudo, because fewer lines of code means less attack surface, right ? And I presume since I’m a desktop user, I don’t need every functionality of sudo. I know pop-os does this, the part i don’t know about is how.

@dalto I only presume but akm (endeavour os kernel manager) should require elevated previleges, no ?

EDIT: I’ve looked into akm and dependencies are: bash, yad and eos-bash-shared. It does require the user to enter sudo password while download/install of kernels though, so indirect dependency, sort of.My guess is opendoas-sudo package would solve this though.

@freebird54 It helps partly, yes. But you’d still need root account active, which is not what i’m trying to achieve. Thank you nonetheless <3

By the way,
Output of grep root /etc/passwd is

and the output of sudo grep root /etc/shadow is

This means root account is enabled and usable with my user password, right ?

Not materially, you are just exchanging one attack surface with another. If you want less attack surface remove both and use pkexec. That being said, I am not trying to dissuade you from using doas if you believe it is more secure. I just don’t think it lowers your attack surface.

I am not sure that disabling root is going to make your machine more secure in any practical way. It may make your machine more difficult to rescue though. You can’t remove the root account, it is needed for many things to function. You could change the shell to /sbin/nologin but I wouldn’t guarantee that won’t break your machine. I would just set the password to some long string of characters if you don’t want to use it.

Further, I am not sure that applications should require sudo but I bet there are probably some that use su which will require your root password. It is probably not common though.

EDIT: It looks like yay and akm require sudo. If makepkg doesn’t find sudo it falls back on su.

EDIT 2: If you want to disable root. Be sure to try it after you are done removing sudo/adding doas. It would be easy to leave yourself in a spot where you can’t elevate privs or switch to root.

EDIT 3: I am not trying to imply that doas is or isn’t more secure than sudo. I haven’t done the research to know either way.


A benefit of using Arch is that any vulnerability that gets discovered in an important utility such as sudo will be fixed in about a day or two, as long as you keep your system updated.

However, if you wish to replace sudo with doas, it is sufficient to install opendoas-sudoAUR. It will automatically pull opendoas package from the community repo as a dependency, and it will uninstall sudo, as it is in conflict with it.

The sudo command will still work, but it will just run doas (it’s just a symlink). Everything should work fine, except the sudoedit command (but who uses that, anyway?).

My recommendation, for what it’s worth, is to stick with sudo. Sure, it’s “bloated,” compared to opendoas, but it’s not like there is any noticeable decrease in performance, and since sudo has such a large user base, it’s more likely that any security vulnerabilities will be discovered, and fixed before much damage can be done.


@dalto @Kresimir Thank you both for replying.

I gave it some thought about this and ultimately decided not to do it simply because sudo has a much larger user base (more eyes on the code) and is an older package (most of the vulnerabilities and bugs should be ironed out).

Seeing someone else have thought the same way (@Kresimir ) further cemented my train of thought about this. Thank you both again.


are you sure about this? now the hacker under your bed with physical access to your computer has an attack door open…

If you are referring to the big sudo bug that was discovered in January, then no, physical access to the machine was not required to gain root access. It was enough to have access to any account on the machine (also via ssh, for example).

If a hacker has physical access to the machine, than there is nothing that can prevent him from abusing it, apart from drive encryption, perhaps.

yeah, no, it was simply a joke, now that the thread is solved…

1 Like


Or sawblades under chair only deactivatable with owner’s farts.

“Did you leave the gas on ?”
“Nah I’m just turning on the PC”