[miohtama]

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.

[im3w1l]

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

[toyg]

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?

[axaxs]

Poettering to save the day with systemd-sudo?

[kuschku]

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

[deckard1]

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.

[megous]

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.

[vbezhenar]

Does it work without GUI?

[magicalhippo]

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

[rogerbinns]

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.

[jeffbee]

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.

[arp242]

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

[masklinn]

> 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

[stouset]

This is why OpenBSD has `doas`.

[umvi]

> 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.

[acdha]

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.

[masklinn]

> 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"

[megous]

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

[young_unixer]

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

Or everyone just switches to musl + busybox.

[anthk]

Or doas. Much simpler.