doas is a userspace utility from the OpenBSD project. From the manpage:
doas — execute commands as another user
If you are familiar with using
sudo to perform actions as another user, then
doas is an alternative implementation of the same goal.
So, why should I switch to
Point 1: Security
sudo is a massive, feature-packed (“bloated”) program. Take a look at the source lines of code (SLOC) for
λ › tokei =============================================================================== Language Files Lines Code Comments Blanks =============================================================================== Autoconf 107 56586 51294 3162 2130 C 329 128324 95141 19607 13576 C Header 87 14984 8603 4901 1480 Happy 2 2839 2600 0 239 JSON 7 236 236 0 0 Pascal 3 1020 964 10 46 Perl 2 418 285 80 53 Protocol Buffers 1 135 121 0 14 Python 10 706 537 51 118 Shell 65 22217 16720 2964 2533 Plain Text 1 1 0 1 0 =============================================================================== Total 614 227466 176501 30776 20189 ===============================================================================
With such a massive codebase, there are many potential points of failure. Since
sudo runs commands as different users, then these points of failures could lead to one of the most devastating exploits: privilege escalation.
This isn’t just theoretical either. Take a look at the CVE list for
sudo, which includes such delicacies as CVE-2021-3156: an off-by-one error that can result in a heap-based buffer overflow, which allows privilege escalation to root. And don’t think this is some old problem now that
sudo is “mature” — the previously mentioned CVE was from January, 2021. It’s not a matter of “if”, but a matter of “when” new vulnerabilities are discovered for
In contrast, take a look at the CVE list for
doas, and the SLOC for
λ › tokei =============================================================================== Language Files Lines Code Comments Blanks =============================================================================== C 17 2435 1648 490 297 C Header 5 986 774 140 72 Happy 1 352 317 0 35 Markdown 1 63 0 45 18 Shell 1 561 412 88 61 =============================================================================== Total 25 4397 3151 763 483 ===============================================================================
doas has ~3k SLOC compared to
sudo’s ~177k. That’s nearly two full orders of magnitude less. While SLOC is not necessarily indicative of a secure implementation, it is far easier to audit a codebase that is 50 times smaller. Just by default,
doas will have a far smaller attack surface than
Point 2: Ease of configuration
Everybody who’s used
sudo at some point has had to wrangle with the dreaded
/etc/sudoers file. This file is so complex, most
sudo packages will provide a utility
visudo just to ensure that users do not create an improper config file and lock themselves out of their system.
Now that may have been a slight embellishment. But the
/etc/sudoers file really is too convoluted for average Linux desktop usage (notice the emphasis on desktop usage: more on this later).
As an example, consider the standard example for allowing a user to run any command:
user ALL=(ALL) ALL
Why are there so many
ALLs? What do they all mean? You can see how easy this would be to misremember. Now, consider the same configuration in
That’s so much cleaner.
Why shouldn’t I switch to
In short: you should not switch to
doas if you actually need the advanced configuration and granularity of
sudo. If you don’t know if you need the advanced features of
sudo, then you do not need the advanced features of
If you are using desktop Linux as a single-user, or even as a multi-user in a family home, then you don’t need all the features of
doas will serve you just as well, if not better.
If you are a sysadmin in charge of an enterprise Linux server deployment, with hundreds/thousands of users, with all sorts of granular
sudo settings, then
doas probably will not work for you.
Alright, I’m convinced. Tell me how to switch.
I can only speak for Arch Linux from this point forward.
doas has been ported over to Arch Linux and is in the official repositories under
Before going forward with the installation, I highly recommend that you open a terminal emulator and log in as root. In the unfortunate scenario that you lock yourself out of
doas, you can save yourself by running commands in this root terminal.
opendoas as follows:
# pacman -S opendoas
On Arch Linux,
opendoas is configured with
/etc/doas.conf. To allow users of the group
wheel to run any command, insert the following line into
If you only wish to let a certain user
user access all commands, then:
What about more advanced configurations?
It’s possible that you may want more advanced configurations, such as letting a user only run certain commands as root, or passwordless command access. Let us show an example that will hopefully cover all the necessary cases.
For example: let’s say that we want any member of the group
powerful to run a certain command
/usr/bin/cmd as user
leader, passwordlessly. Then:
permit nopass :powerful as leader /usr/bin/cmd
It’s as easy as that. Very readable and human-friendly. More details can be found in the (very concise) doas configuration manpage:
man 5 doas.conf.
doas is asking for my password every time!
sudo never did this! I’m never coming back here again!
doas will ask for your password every time you run a command. While this is good for security, it can make certain command chains (
doas cmd1 && doas cmd2 && doas cmd3 [...]) tedious. To emulate
sudo timeout behavior, add
persist to your configuration like so:
permit persist :wheel
From the manpage:
persist After the user successfully authenticates, do not ask for a password again for some time.
I want to completely remove
sudo and only use
There are multiple ways to do this. Most people will recommend uninstalling
sudo and aliasing
alias sudo=doas in your shell’s rc. I don’t like this method, as it is contingent upon sourcing the shell’s rc in order to get
sudo functionality. What about scripts and applications that do not source the rc, or reset the environment before running? Instead, we should make a symlink on the filesystem itself,
/usr/bin/sudo -> /usr/bin/doas.
Luckily, there is a package in the AUR
opendoas-sudo that does this for you, so you don’t have to manually mess with parts of the filesystem that could conflict with the package manager. I use this package myself, and have had no issues.
If nothing else, you should take from this post that
sudo is a very large, complicated mess of a program. And no program is infallible. Even if you don’t switch to
doas today, keep it in the back of your mind as a less bloated alternative to