Why bother switching at all
I ran sudo for years without thinking about it. It’s the default assumption everywhere, it’s well documented, and nobody ever got fired for installing it. But at some point I started actually reading what I had sitting on my boxes, and sudo is a surprisingly large piece of software for what most of us use it for, which is “let this one user run this one command as root without typing the root password.”
doas does that. That’s basically the entire feature set. It came out of OpenBSD, it’s in the FreeBSD ports tree as security/doas, the config file is about four lines long, and I have never once had to go looking for a man page mid-task to remember syntax. That last part matters more than it sounds like it should.
Installing it
Nothing exotic here. Either grab it from packages or build the port if you’re the type who likes to see things compile:
- pkg install doas — fast, does the job, fine for most people
- cd /usr/ports/security/doas && make install clean — if you want to fiddle with build options, which realistically you won’t need to
There’s no daemon, no service to enable, nothing to add to rc.conf. It’s a setuid binary and a config file. That’s the whole install.
The config file
Everything lives in /usr/local/etc/doas.conf, and it doesn’t exist by default, so you create it yourself. Permissions matter here — root should own it and it shouldn’t be world readable, though doas will yell at you if you get this wrong rather than silently failing open, which I appreciate.
A minimal config for a single admin user looks like this:
- permit persist lperez
That one line lets the user lperez run any command as root, and persist means it won’t re-prompt for a password for a few minutes after a successful auth, same as sudo’s timestamp behavior. If you want it to ask every single time, drop persist. If you want to restrict it to specific commands instead of blanket root access, you do it like this:
- permit nopass lperez cmd /sbin/zfs
- permit nopass lperez cmd /usr/sbin/pkg
nopass skips the password prompt entirely for that command, which I use for things I run constantly and don’t consider dangerous enough to re-auth for, like checking zpool status. Anything that touches disks destructively or installs software still asks.
What actually breaks
The honest list of things that trip people up:
- Environment variables don’t pass through by default. sudo has a pile of env_keep rules baked in or configurable; doas strips almost everything unless you explicitly add a keepenv line. If a script you run under doas suddenly can’t find something it expects, this is almost always why.
- No group-based rules out of the box the way sudoers supports %wheel. doas does support groups with the :groupname syntax, but if you’ve been copy-pasting old sudoers fragments out of habit, the syntax difference will bite you once before you adjust.
- Tab completion for commands after doas isn’t as polished in some shells compared to what people are used to with sudo setups that have been tuned for years. Not a dealbreaker, just a small daily friction you’ll stop noticing after a week.
- Some third-party scripts assume sudo is in the path and call it directly. You can symlink doas to a script that translates sudo-style invocations if this annoys you enough, but I mostly just edited the two scripts I actually cared about and moved on.
Keeping both around during the transition
I didn’t rip sudo out on day one. I installed doas alongside it, used doas for everything new, and let muscle memory catch up over a couple of weeks. Eventually I noticed I hadn’t typed sudo in a while and uninstalled it. If you’re nervous about a machine you can’t physically walk up to, do the same — there’s no reason to burn a remote box over a shell habit.
One thing worth doing regardless: keep a root shell open in a separate terminal while you’re testing your doas.conf for the first time, especially if you’re restricting commands rather than granting blanket access. Locking yourself out of su with a typo in an untested config file is an old mistake, and doas is no exception just because the file is short.
Is it actually better
Not dramatically, no. It’s not going to change your life. What it does is remove a dependency I wasn’t using the features of, shrink the attack surface a little, and give me a config file I can read top to bottom in ten seconds instead of skimming past a hundred lines of commented-out examples. On a desktop or a small jail host, that’s enough of a reason for me. On a big multi-admin production box with complicated per-team access rules, sudo’s extra plumbing might actually be doing work for you, in which case, don’t switch things just because some blog told you to.
For my own machines — a couple of jails, a desktop, a backup box — doas has been running for a while now with zero surprises, which is exactly the bar I want a privilege-escalation tool to clear.