> All I want it to do is: ensure authorization, raise privileges, call exec.
A lot of people do want to do more, especially in some corporate contexts people run very complex sudo setups.
Consider something like Linode; maybe you want some of the more experienced support people to issue some commands on some machines, without having full control. And you've got a gazillion machines so you don't want to setup each one individually (as well as revoke access once they leave). Things can get fairly complex pretty quickly once you move out of simple settings.
For my desktop machine, doas is perfect. For our servers it's fine too because we have just a few people with access. But I'm not everyone of course.
doas was explicitly written to NOT cover all use cases, and that makes it better for the (simpler) use cases it was intended to solve, at the price of not covering other use cases of course.
Maybe I’m misunderstanding you but doas handles the use-case you describe. I can enforce that some users can issue some commands on a given machine in doas.conf
As someone who manages infra including Linux and OpenBSD and does configure sudo and doas in this way, I’m pretty sure 99% of users would be fine with the simpler tool. Maybe the simpler, safer tool should be the default.
I don't think doas can integrate with PAM, LDAP, and all of that, and the possibilities doas.conf give you are vastly less than what the sudoers file gives you.
> I’m pretty sure 99% of users would be fine with the simpler tool
That probably sound about right, give or take a few %; it probably should be the de-facto default, with sudo being used when doas doesn't suffice. But the question was "why on earth is sudo so complicated?", and the answer to that is "because some people want/need complicated stuff".
From a security standpoint point you would want the opposite, the stricter doas on the more exposed servers and and the less strict sudo on the personal desktop.
That's the problem. We use sudo that autorizes user by it's SSH key via its auth socket... so we can essentially authenticate sudo via smartcard (Yubikey), and not keep the private key on user machine.
Some other folks use LDAP to get the sudoers files or even allowed ssh keys itself
There is also "just run thing as user" but also "set up same way shell would and pretend user logged as different user", first one is simple, second is a bunch of setup, copying env variables etc.
There is a good argument for splitting "just run app as different user" and "everything else that has to do with interactive shell and admins doing things on server" but now you have 2 configs to manage...
"ensure authorization" and "raise privileges" and "call exec" are all behind plugin-based architectures to allow for people to set up various ways to do things. The simple example: why do you only need to type in the password once per session/30 minutes calling sudo in most environments? How can people set things up with a hardware key? How do you make just some commands work and not others?
That being said I don't think sudo's code is complicated? It's big because it has all of these plugins supporting various mechanisms, but each file is pretty straightforward, and the control flow is really not that hard (after you get that it's plugins).
The documentation describes the configuration as a context free grammar using EBNF notation. This is impressive, but maybe a little more complicated than I want to get with a basic security tool. I suspect most people who don't have to modify it very often are going to secondary sources, like tutorials or stack overflow, and copying examples from there.
IMO, a more complex grammar allows for better descriptions. The only real type of grammar simpler than CFG is a regular expression. That's pretty limited, although (the older part of) CSS doesn't need more than that. But as soon as you want a nested construction, hierarchy or simply nested parentheses, you need a CFG. If it's difficult to configure, the problem is the (configuration) language, not the power of its grammar.
And there are excellent parser generators out there. You don't have to fear introducing bugs via them.
Yea I sometimes have to refresh my memory on sudoers or just search for what I want to accomplish, hoping that someone has already handled the potential security gotchas (eg, exact fullpath command should always be specified).
I agree, in some typical cases I only need to specify "<user> can become root" or "<user> can become <user of group>", kinda like doas already does I think.
I'll probably try out doas when the next such special need arises, then resort to sudo if doas is insufficient for some reason.
> [...] as a context free grammar using EBNF notation. This is impressive, but maybe a little more complicated than I want to get with a basic security tool.
I apologize if I'm being trite, but Context Free Grammar doesn't mean that the semantics of whatever that grammar describes is simple. It just means that it's simple to parse into ... something. Parsing a CFG is also not impressive in the slightest. It is, in fact, trivial since the 1970s. Anyway,
You shouldn't be scared of the CFG bit... you should be scared of the semantics.
A lot of people do want to do more, especially in some corporate contexts people run very complex sudo setups.
Consider something like Linode; maybe you want some of the more experienced support people to issue some commands on some machines, without having full control. And you've got a gazillion machines so you don't want to setup each one individually (as well as revoke access once they leave). Things can get fairly complex pretty quickly once you move out of simple settings.
For my desktop machine, doas is perfect. For our servers it's fine too because we have just a few people with access. But I'm not everyone of course.
doas was explicitly written to NOT cover all use cases, and that makes it better for the (simpler) use cases it was intended to solve, at the price of not covering other use cases of course.