[sigio]

Nope... sudo is just this sudo in 99.99% of the cases. There are some alternatives, such as *bsd's doas, and others, but all but doas and su are so non-popular and outdated that I would not recommend using them, as they probably have way more security issues.

[wahern]

doas is just OpenBSD. You can install doas from ports on NetBSD or FreeBSD, just like you can install doas on Linux.

OpenBSD dropped sudo from the base OS several years ago. sudo just became too complex, tailored to the feature creep demanded and required (PAM, ugh) by Linux users.

[turminal]

Briefly going through their website (sudo.ws) I am seriously wondering why anyone would want to put some of those features in a privilege management tool.

[wahern]

Todd Miller is a sharp developer and core OpenBSD contributor. I can only imagine the deluge of requests and pressure he faces to expand sudo. There's no end to the crazy stuff corporations demand, especially when it comes to integration--audit, logging, ldap, etc.

[toyg]

> Todd Miller is a sharp developer and core OpenBSD contributor.

I wonder why OpenBSD wrote their own version. Could it be that, knowing how the sausage is made, they thought it was better to have a salad...?

[masklinn]

> I wonder why OpenBSD wrote their own version.

Wonder no more: https://flak.tedunangst.com/post/doas

> I started working on doas quite some time ago after some personal issues with the default sudo config. The “safe environment” was under constant revision and I regularly found myself unable to run pkg_add or build a flavored port or whatever because the expected variables were being excised from the environment. If I had been paying attention, keeping sudoers up to date probably would not have been such an ordeal, but I don’t like change.

> The core of the problem was really that some people like to use sudo to build elaborate sysadmin infrastructures with highly refined sets of permissions and checks and balances. Some people (me) like to use sudo to get a root shell without remembering two passwords.

> […]

> Talking with deraadt and millert, however, I wasn’t quite alone. There were some concerns that sudo was too big, running too much code in a privileged process. And there was also pressure to enable even more options, because the feature set shipped in base wasn’t big enough. (As shipped in OpenBSD, the compiled sudo was already five times larger than just about any other setuid program.) Hurray, tension. It wasn’t the problem I was trying to solve, but it was an opening from which to launch my diabolical plan.

[toyg]

Lol - now that you quoted it, I actually remember reading this post back then... but at the time I had just assumed sudo was a linuxism they didn’t particularly appreciate (openbsd people can be... petty), I didn’t know one of their core devs was maintaining it.

[krylon]

> I wonder why OpenBSD wrote their own version.

With most other projects, I would smell a major case of Not-Invented-Here, but the OpenBSD developers seem to have an impressive track record of actually learning from mistakes, both from their own and those made by others.

> knowing how the sausage is made, they thought it was better to have a salad

I love that phrase! (Coincidentally, an engineer working in food processing once explained to me how chicken nuggets are made (while we were eating!), I have mostly avoided them ever since...)

[LargoLasskhyfv]

> There's no end to the crazy stuff corporations demand, especially when it comes to integration--audit, logging, ldap, etc.

Why should that be of concern to casual home use? Why do parts of a factory have to trickle down into my home? Wouldn't that be like the need to have a cow to drink milk, or a farm to have something to eat instead of a more apt product to buy for a reasonable price and in good quality?

[turminal]

The bigger a piece of software is, the more opportunities there are for bugs. And the correlation isn't linear.

For home users there is doas, also written by a OpenBSD developer. It's really simple, but I never found anything to be missing for my use case. All the logging and auditing and whatnot can (and imo should) be performed somewhere else.

[acct776]

doas has a much smaller attack surface, and is worth checking out.