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.
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’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".
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...
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).
And have an audit log? And clean the environment? In particular the path? Dynamic library path?
Still, I suspect "ensure autz" is the problem (implies Pam, 2fa, kerberos, etc etc).
And there are excellent parser generators out there. You don't have to fear introducing bugs via them.
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.
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.
function sudo { su -c "$@" root }