Hacker News Reader

Comment by jeffbee | Hacker News Reader

All you need to know about sudo and frankly most other pieces of the Linux userspace is that it is undertested. The commit that added this flaw to sudo claims to fix a parser bug but includes no tests. There is no reason for the author, the reviewer (if there even was such a person), or anyone else to believe that the bug existed or was fixed by this change. The pull request that supposedly fixes this CVE also includes no tests. There is no reason anyone should believe this fix is effective or complete, or that it does not introduce new defects. This is the result of people who stubbornly refuse to practice even the most basic good engineering practices, like testing and code review, while at the same time using the industry's most dangerous high-level language. As long as this type of thing continues, our tools will remain at a very low level of safety, reliability, and correctness.

View on HN

"All you need to know about sudo and frankly most other pieces of the Linux userspace is that it is undertested"

Fair enough but what do you recommend?

Me, I try to keep people out of my systems that I don't trust. This particular snag needs local access but I will grant you that my web server or other exposed service might provide a local interface.

Instead of throwing your hands up and screaming "crap" you do your risk assessment and attempt to mitigate as best you can. I read a lot of blogs and have a fair amount of logging and analytics lying around the place (and that's just at home).

Fairly recently I found that my wife's car had loose nuts on the front nearside wheel. That was a change to fix a worn tyre for obvious safety reasons but for whatever reason the fixings were not done up properly. I think they were done up finger tight but a distraction caused the mechanic to forget to use a spanner (wrench) to finish the job to spec. The wheel seemed to work fine but you would get a low rumble sound on corners. It was not a trivial to diagnose fault because you had to notice it before failure - I'm a (non chartered) Civ Eng and IT bod but not a mechanic. There is a minimally screwed on plastic cover that stopped the bolts from flying out - not much.

A car wheel is a thing we can all look at and see that the four bolts are not working properly, once you remove the plastic cover and see them wobble.

Now that is what you can do to protect yourself (risk assess, mitigate etc.) However there should also be something that protects "civilians" and I think that is what is missing. I'm not too sure how we do that.

> Fair enough but what do you recommend?

MirageOS unikernels like were mentioned yesterday? Get away from running network services on Linux entirely?

Does it have full support for all the kinds of stacks people are running on Linux today? Is there a robust ecosystem of MirageOS users online able to help troubleshoot issues from the simple to the arcane? Is it supported by VPS providers the world over?

Personally, while I doubt these are the case, having never heard of MirageOS before, I'm willing to be proven wrong. However, if the answer to any of these is "no", I have a hard time seeing how "just abandon Linux wholesale for NewShinyThing" is a viable option for more than a tiny subset of users. (Even if they're all "yes", it's still a wildly unrealistic expectation...)

> Does it have full support for all the kinds of stacks people are running on Linux today?

No, of course not; the only thing that supports everything that Linux supports is Linux. But most use cases don't use every part of Linux.

> Is there a robust ecosystem of MirageOS users online able to help troubleshoot issues from the simple to the arcane?

I doubt it, but how do we get to there from here except by more users starting to use it?

> Is it supported by VPS providers the world over?

Yes, since what you build is just a VM image.

> However, if the answer to any of these is "no", I have a hard time seeing how "just abandon Linux wholesale for NewShinyThing" is a viable option for more than a tiny subset of users. (Even if they're all "yes", it's still a wildly unrealistic expectation...)

I don't disagree as such, but I do think that at this point building anything on these insecure foundations is throwing good money after bad / building castles on sand. Probably 95% of the time you build something that serves your present business purposes, accept a certain amount of insecurity, and get on with your life. But it's worth putting a bit of effort into looking for better ways to do things.

Use Actually Portable Executable which enables you to compile textbook C programs as unikernels that boot on bare metal, as well as execute natively on all the existing operating systems too (without needing a runtime or interpreter). We've been working hard to democratize ring0 privileges since spectre has made the performance costs of having an operating system too high: https://github.com/jart/cosmopolitan/issues/20#issuecomment-...

The libc is a runtime.

By runtime I meant to say external runtimes. Your cosmo binaries are statically don't depend on anything except stable kernel interfaces, when you run on mac/nt/linux/bsd. That means it doesn't need to link any .so files like the glibc runtime. Therefore you won't be impacted by things like linux distro versioning and incompatibilities.

Much of the point of suggesting Mirage was to get away from C - my position is that the correctness costs of C's undefined behaviour (as implemented by real-world C compilers), limited testing support, poor dependency management and so on are too high.

One of my goals with Cosmopolitan is to attract developers who build high-level languages. MirageOS depends on OCaml which depends on C. We need a sturdy foundation at the lowest levels that can enable these visions by helping high-level environments be successful. Cosmopolitan can be that foundation. For example, the codebase has 192 test programs. Much focus has been placed on using the Undefined Behavior Sanitizer and Address Sanitizer to vet everything. My past experience was working on projects like TensorFlow and I started security initiatives like Operation Rosehub which together helped us have the highest performance software infrastructure that's safer too.

> OCaml which depends on C

How so? The OCaml compiler is written in OCaml and bootstraps itself.

In short: There's nothing that you can do

Longer: One of two things -

1. Choose the most boring software possible, trust that the process will work as expected and that you're no worse off than anyone else. Update your software regularly

2. Choose the simplest, most robust software possible (Alpine, OpenBSD, etc). In this case, doas instead of sudo. Pray that works better than everyone else or that you get some benefits through obscurity. Still get surprised every so often. Update regularly

Either way, modern software has gotten complex enough that there's few options for the average person

> Fair enough but what do you recommend?

why do you need to have sudo? I'm perfectly fine without it. sudo is maybe useful in the case where others on the system don't need to know the a password to run as someone else (including root) but need to be able to do that anyway. sudo seems to have gotten a big installation bases through ubuntu and everybody thinks it's normal now, but really for me it's not.

I want to start and stop a couple of systemd services remotely. Currently I expose the command with sudo and run it under a remotely connected user. What are other options?

In your case either use plain /sbin/su: https://man7.org/linux/man-pages/man1/su.1.html or login via root. Your use case sounds very sudo-like, thought. Probably stick to sudo.

It's a batch job. Ah, I see it mentions runuser, will check it.

You don't actually have to be root at all to manage systemd services. If you give the user `org.freedesktop.systemd1.manage-units` in Polkit then they can just run systemctl as their user and it will work.

If you only want to allow specific units the authorizer is passed the unit under `action.lookup("unit")`.

sudo doesn't have to grant full root access to everyone in the group. It can be set up such that certain users only have the ability to run specified commands as root, which is handy for orgs where you might have a group of tier 1 techs that you want to be able to run certain scripts (written by tier 2 or 3, of course) that require root, but you don't trust the engineers enough to have root access to everything.

It is almost always the case that a sufficiently malicious user can find a way to turn that into full blown root access.

So that means they should get full blown root from the beginning?

IMHO yes because then you treat the access with the gravity that is required.

> The commit that added this flaw to sudo claims to fix a parser bug but includes no tests. There is no reason for the author, the reviewer (if there even was such a person), or anyone else to believe that the bug existed or was fixed by this change.

"The PR does not include tests" is not the same as "nobody performed any tests" is not the same as "nobody actually noticed a bug".

And of course, it's perfectly reasonable to form beliefs about code from reading it.

"You can't prove no one tested that!" is not really a good basis for robust software design.

In addition to the value of repeatability, it’s just being a good human to show and share your work.

Tests you perform locally should probably be described, if not encoded into something that other people can run as well.

> And of course, it's perfectly reasonable to form beliefs about code from reading it.

Broadly yes, but it would be hubris to claim you can tell the correctness of all code from merely looking at it.

For some code you should be able to do this, and if you can't then I don't think you should be writing code.

Coding is not brute forcing. I feel like this is taking an extreme position at the complete opposite end from not testing anything.

EDIT: Misread the comment I replied to. I agree that it is not likely that anyone can tell the correctness of all code from merely looking at it.

For some code, yes. What about a complete refactor of the core functionality of said program, with parallelism and the like?

I misread the comment I think, but either way, I am not arguing against automated tests, I was just trying to point out that for some fragments of a code base you should absolutely be able to tell correctness by looking at it.

Even if there were basic unit & regression tests, this bug might not have been caught. This bug should have gone through detailed security review and should probably also undergo fuzzing.

You can bet your bottom banana that the GRU, the NSA, Chinese state security, and the mob have all thoroughly fuzzed sudo and are sitting on the results.

It just seems SO EASY to add a test for this problem, literally the relevant test input is one slash by itself, or any string ending in a slash! So simple! If I sent a change like this at work, no matter how trivial, that said it fixed this bug but I didn't send any tests, the reviewer would reject it out of hand or, probably, just silently ignore my change. But that's the real problem here. This program is a monograph. There are no reviewers and there are, consequently, no standards.

Single persons often have superhuman standards. It is easy to see that most of the best works in math or art were produced by an individual.

Code review can work, but often it doesn't. There are countless examples of projects with "strict" review requirements that have similar issues (whereas qmail only had one).

Writing tests is the important thing, it keeps you honest.

31 CVEs later I think it's safe to say that this particular author does not possess superhuman standards. How much more evidence would we need?

It sounds like you'd find great pleasure in writing harnesses for oss-fuzz. Google has found and reported over 25,000 bugs in 375 projects, but they need people like you to help wire up new projects.

You can get started here: https://google.github.io/oss-fuzz/

Maybe expecting projects that mostly consist of a single guy working on it in their spare time to be "NSA proof" isn't really realistic?

Folk love to bring up "responsibility" and all of that, but you can't really expect people to bear the responsibility of the world on their shoulders for their spare time projects. It's neither realistic nor fair.

No, but having tests is an acceptable baseline.

There are tests. Are there enough tests? Maybe not. But people can do in their spare time whatever they want, including writing code without tests.

People can do what they want in their spare time, true, but that it is their spare time does not make the action responsible or irresponsible, nor does it shelter them from responsibility.

Not wearing a seatbelt when at work or in your spare time is irresponsible.

Writing code, without tests, that others use (and for security at that) is irresponsible.

> Writing code, without tests, that others use (and for security at that) is irresponsible.

You can choose to run this code, or you can choose not to run this code. It's really up to you.

This is very different from a sealbelt, as I can't choose to not have an accident with you, potentially causing a needless fatality.

This code is advertised as a security tool, is it not? The only reason anyone runs sudo is because it (supposedly) improves their security. I think some responsibility comes with that.

So people should be obliged to spend more of their free time?

I know this is not exactly what you're trying to say, but it is what it comes down to.

Hmm. Maybe we shouldn't let unlicensed hobbyists expose their software to the internet - plenty of other things are too dangerous for unlicensed hobbyists to do. Though frankly the standard of commercial code is no better at the moment.

If they don’t like using their free time to write code they don’t have to, it’s free time not work.

So, what it actually comes down to is that they didn’t bother to write tests. There was no time pressure, there was no urgency or requirement, they just couldn’t be bothered to do that prior to release. If there’s a note somewhere saying “I know it’s not quite done...” then I’ll let it slide.

Have you seen something along those lines?

> So, what it actually comes down to is that they didn’t bother to write tests. There was no time pressure, there was no urgency or requirement, they just couldn’t be bothered to do that prior to release.

Kindly go to the source repository.

> If there’s a note somewhere saying “I know it’s not quite done...” then I’ll let it slide. Have you seen something along those lines?

That's what a TODO file is for. There is one you can browse to here: https://www.sudo.ws/repos/sudo/file/tip/TODO

There is also literally a dozen lines in the LICENSE file saying that the software is not quite production ready (THE SOFTWARE IS PROVIDED "AS IS") and should not be relied upon (THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS).

It's all spelled black on white, not sure what you would want more from the author?

From the comment I originally replied to:

> people can do in their spare time whatever they want, including writing code without tests

I did not refer to the Sudo project at all, so you might want to redirect your post to someone who did.

I don't use sudo to improve my security; I use sudo because it's what I've become familiar with.

I don't want to come across as pedantic - the point I mean to make is that I think a lot of people use sudo without thinking about it much. Sudo's just "the way to use linux" for a lot of people I know.

I don't think the sudo contributors should be labelled as irresponsible, because everything they've added to the project is available for the public to see and scrutinise. I don't think they've ever mislead people; rather that people have assumed things.

Maybe people who care about security will notice now that sudo doesn't have comprehensive testing, and will make their own alternative.

> This is very different from a seatbelt

You can choose to wear this seatbelt, or you can choose not to wear this seatbelt. It's really up to you.

Y'know, I don't agree with you in general, and you did put this in general terms.

But this is frakkin sudo we're talking about.

It's a wonder that anything works, ever.

Yeah, this goes back to the whole "Open Source and corporate funding" story. As far as I can find, sudo doesn't get any direct funding at the moment, although various companies have undoubtedly contributed patches.

It’s nice when those with differing viewpoints can find common ground over their profound disappointment with the world (or at least their profession).

Reading the code of important open source projects is not for the faint hearted!

From https://www.sudo.ws/license.html

> THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

If you don't like this license, you're free to use other software.

What’s that got to do with what I wrote?

Nothing, as far as I can see. If someone writes some crappy security software and hides behind a licence that only means those relying on it have joined them in being irresponsible. Responsibility multiplies, it’s not zero-sum.

Parent's comment has got everything to do with yours: you are feeling like the software somehow owes you to be merchandable and fit , while the software's license explicitely rejects ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS .

There is a large disconnect here.

That's fine, existing software comes first, decent software comes second, sudo is the former. That said, it's a good candidate for riir (safety, right?), but riir happened to grep instead.

The thing is, "do what thou wilt" is clearly indefensible as an engineering standard, and I doubt you would disagree. So yes, I can't force anyone to write tests.

However, I do want to see programming as a culture adopt a higher standard when it comes to checking their work, and I think the continued prevalence of bugs like this are an indicator that we actually need to do so. I'm not asking for NSA-proof because that's not reasonable. But memory safety is a solved problem, and we need to be putting in the legwork to make more of our stack memory safe.

Maybe something that’s sole purpose is privilege escalation, like sudo, should come with some expectation of responsibility.

No, you can’t. I think the blame shouldn’t be on this author, but on those choosing to install it or, worse, choosing to ship it on their OS.

OpenBSD replaced sudo with doas (http://man.openbsd.org/doas) in 2016 (https://www.infoworld.com/article/3099038/openbsd-60-tighten...). It’s a safe bet it’s more secure than sudo.

doas is a a really good replacement.

Sudo was (maybe still is?) an OpenBSD project. I don't believe it originated there, but their code forms/formed the basis for sudo pretty much everywhere, much like OpenSSH.

> It just seems SO EASY

Then do it! On your own time, rather than complaining that someone else didn't do it on theirs!

Does the project have a testing framework in place? How is the project built and distributed? Can testing be integrated into its CI/CD pipeline? Is there a CI/CD pipeline? Adding frameworks and infrastructure to a project is one of those things that is a lot more work than it appears to be. They should do it, for sure, but I wouldn’t dismiss it as trivial on a decades-old system that was never built for it.

We’d all like that, true, but look here:

https://github.com/sudo-project/sudo/graphs/contributors

That’s one maintainer, not even full time according to his résumé. What you just described is multiple specialists and some supporting tools, so another way of looking at this is to ask how much value the IT world has gotten from sudo but not contributed back in support.

When something is this widely used, it’s easy to forget that the answer to who should do more isn’t the one person who actually steps up to keep it alive.

Does he moonlight for the NSA?

This response is the “must be aliens” of security. If you remotely think this is the case, ask whether one of the top intelligence agencies in the world would be more likely to attract attention to a deep cover operation many, many years in the making or would invest in making sure that the bug was well concealed so nobody else would be able to use it on, say, .gov servers. If you remember Dual EC_DRBG I know which one I’d bet on…

It was meant as a joke. Lighten up.

Having worked with the IC for decades, I'm well aware of what's going on.

I figured it was a joke but it's about as original as a standup routine complaining about airline food.

Wow he changed two million lines of the sudo codebase over the project history and made 10,548 commits. That's bonkers. Sudo is clearly doing a lot more under the hood than I thought it did. A simple security critical command shouldn't have that much churn. It should arc towards immutability like TeX, which has had like twelve changes in the last 40 years.

> Sudo is clearly doing a lot more under the hood than I thought it did.

There’s a number of reasons openbsd dropped it, and all of them are fundamentally rooted in size and complexity: https://flak.tedunangst.com/post/doas

OpenBSD is a fabulous project. I've been working on tool called Cosmopolitan which helps Mac/Linux/Windows/FreeBSD developers write software that's compatible with OpenBSD: https://github.com/jart/cosmopolitan/blob/master/libc/sysv/s... As you can see, I've studied these systems a lot and I've got to say that OpenBSD is the closest to the Bell Labs roots I've seen from community distros. It takes a certain degree of judiciousness to maintain that authenticity and the clairvoyance w.r.t sudo should be all the proof we need that OpenBSD is up to something good.

doas is a wonderful alternative to sudo.

For one, the config file is actually easy enough to read properly.

Sidebar: Wonderful post, but what an awful fake loading bar. Every time I switch from the tab / window to something else and switch back to continue reading I'm interrupted by it for no reason.

You're supposed to disable javascript in your browser.

A Turing Award winner once said, “Program testing can be used to show the presence of bugs, but never to show their absence!"

Sounds like a very smart person. Much of the value in the test is showing that the old revision fails it. If I were fixing this bug, first thing I would do is write the test and make sure the existing code fails. If it doesn't fail, that means I don't understand the problem yet. Then I fix the problem and commit both the fix and the test. I don't just discard the test, because it is valuable to know that in the future nobody re-introduces the exact same flaw (this regularly happens in open source projects).

I agree. Keeping the test around provides a safety net (a bug repellent of sorts) for the next person the comes along. The test also serves as a documented history of the bugs of the past. The problem is that test does not guarantee the injection of future bugs of a different type. I don't think any amount of testing will. That's not to say we shouldn't write test, we should just be aware of the limits of testing.

A journey of a thousand releases begins with the first unit test.

Everyone has decided to stay home this year, though.

> people who stubbornly refuse to practice even the most basic good engineering practices, like testing and code review

That is not fair. This software is maintained by Todd Miller, the well known OpenBSD developer, and has both tests and certainly discusses code proposals. Not everyone has to use github or the language de jour to be useful.

> This software is maintained by Todd Miller, the well known OpenBSD developer

Ironic that OpenBSD dropped sudo in favor of a much simpler utility.

I think the design of the relevant code is worse than the lack of relevant test coverage. The problem solved insecurely by the code instead seems like an obvious target for lexical and syntactic analysis (and this has been so since the sixties, I think).

Yes, please at least use re2c when parsing anything more complicated in C. The result is much more readable, and integration costs are pretty low, and you still keep a lot of flexibility in how you structure your code.

Did you just call C a high level language?

Technically, it is. But usage of the term has shifted a lot over the last 50 years.

Indeed,

"C Is Not a Low-level Language, Your computer is not a fast PDP-11."

https://queue.acm.org/detail.cfm?id=3212479

Stopped reading your comment after the first sentence because that’s all I needed to know.

Another question is who wants to maintain four decades old GNU C soup? It was written at a different time, with different best practices.

In some point someone will rewrite all GNU/UNIX user land in modern Rust or similar and save the day. Until this happens these kind of incidents will happen yearly.

> It was written at a different time, with different best practices.

Not that I have any faith in modern "best practices". I'm imagining `grep` written in modern a modern language like JS and I shutter when I think of the hundreds of micro-dependencies like "left-pad" that would need to be downloaded to make it work.

Maybe it's fair to say that systems programming languages are in a better state in terms of modern best practices than scripting languages.

I actually like some modern grep alternatives, like `ag`.

Try https://github.com/BurntSushi/ripgrep – it’s across the board better, and one of the best personal productivity boosts you can make if you use grep frequently.

> Not that I have any faith in modern "best practices". I'm imagining `grep` written in modern a modern language like JS and I shutter when I think of the hundreds of micro-dependencies like "left-pad" that would need to be downloaded to make it work.

You don't have to imagine: `ripgrep` exists and has all of 10 direct dependencies, 4 of which by the same author because they extracted features / systems from ripgrep (or developed them separately from the start) as they were useful on their own e.g.

* regex, for obvious reasons

* ignore to match and apply ignorefiles (gitignore and friends which ripgrep takes in account by default)

* bstr for conventional utf8 strings rather than guaranteed

* grep intends to be essentially "ripgrep as a library"

> someone will rewrite all GNU/UNIX user land in modern Rust or similar

Or everyone just switches to musl + busybox.

Or doas. Much simpler.

Rewriting sudo is a weekend project*. Getting people to adopt it is a many-year political campaign.

You can bet your last dollar that if the "right" RedHat or Debian developer rewrote sudo with feature parity, it would be adopted by all major distros in a couple of months. It's the sort of thing nobody really cares about except OpenBSD (which wrote their own).

The problem is feature parity. Most rewrites cannot guarantee that off-the-bat, so they end up struggling to persuade people to switch - why break stuff that works just fine and lose features, in the name of some engineering purity?

Poettering to save the day with systemd-sudo?

https://www.youtube.com/watch?v=TkR9QWuoyJ8

Polkit-exec (pkexec) already exists, has much better security, and integrates with your DE instead of expecting passwords on the terminal.

This thing?

https://gitlab.freedesktop.org/polkit/polkit/-/blob/master/s...

Which also seems to not have tests. In fact, the only tests I'm seeing are from 2 years ago.

https://gitlab.freedesktop.org/polkit/polkit/-/tree/master/t...

> has much better security

It's using D-bus. My faith in D-bus security is close to my faith in seeing a fresh Linux install with zero D-bus error messages from apps. Which is to say, nonexistent.

> integrates with your DE instead of expecting passwords on the terminal.

There's nothing inherently insecure about passwords on the terminal, and certainly nothing a DE can do better. I have yet to see a display manager or lock screen app that knows what the hell PAM is doing. Try doing even the simplest things with PAM, such as getting a fingerprint reader or Yubikey working, and every single display manager simply chokes.

I'm not sure which is more of a Byzantine mess: Linux authentication and authorization, or Linux audio.

PAM is fun. https://github.com/systemd/systemd/issues/16813

With all the .so modules loading into some process, etc. Some questionable design in sshd makes it lock up completely for all incoming connections when used with PAM and when pam module ends up in infinite loop.

Nevermind that systemd pam modules pull in a shitton of stuff, including dbus, into any process that tries to use PAM for auth, these days.

I guess it all runs as root, too. sshd at least tries to fork a child for all this and waits for it and kills it, so that the parent process can't be polluted. It just has no timeout when waiting for result, and doesn't accept further connections when waiting.

Sometimes it's better not to look too deep under the covers.

How else would you implement PAM? The whole point is that you can write arbitrary code to implement whatever custom authentication policy you have, so it needs to be able to dlopen things. And if you don't like the PAM policy written by your distro, you're free to change it by implementing your own authentication policies, or dropping things you don't care about (like systemd, you can configure PAM to just use /etc/passwd and /etc/shadow if you like).

sshd needs to run as root (obviously) because it grants login shells to people, so it needs to run in a privileged context. And the PAM modules it executes also need to be run as root, because PAM modules need to do things like read /etc/shadow.

https://man.bsd.lv/login.conf.5#AUTHENTICATION documents OpenBSD's system, which revolves around running /usr/libexec/auth/login_<foo>. OpenBSD's system doesn't let you do the stack-of-libraries thing that PAM does, but having one binary is a lot simpler.

(In the past, OpenBSD had a login-locally-or-via-Kerberos binary there, which does show the downside of that approach over PAM's more flexible approach.)

Does it work without GUI?

That would indeed be a huge feat of programming skill! I refer you to the configuration file documentation to treat as a spec: https://www.sudo.ws/man/1.8.3/sudoers.man.html

Implementing a subset of sudo is a weekend project, for some values of useful.

That's part of the dark outcome of so many untested features: it makes it easy to cast FUD upon any potential replacements. As we have no black-box test suite that shows `sudo` implements all of these features, so we also cannot have faith that any replacement would. Ideally it should be possible to run sudo's black box tests against any potential replacement. To start with, we need those tests.

There are actually a bunch of tests for the sudoers file format.

> Implementing a subset of sudo is a weekend project, for some values of useful.

openbsd dropped sudo for "weekend project" `doas`, in no small part because it does not support most of that stuff.

Here's the configuration file documentation: https://man.openbsd.org/doas.conf.5

This is why OpenBSD has `doas`.

Reply on news.ycombinator.com