[jorvi]

> Sudo has released a security update to address a critical vulnerability (CVE-2025-32463) in its command-line utility. This vulnerability allows an attacker to leverage sudo's -R (--chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file.

People start making sudo more secure by replacing it with sudo-rs

You: "why are we rewriting old utilities?"

[cv5005]

>CVE-2025-32463

Looks like a logic bug to me? So rust wouldn't have helped.

Those are exactly the kind of bugs you might introduce when you do a rewrite.

[danudey]

One great way you can make things more secure is by reducing attack surface. sudo is huge and old, and has tons of functionality that almost no one uses (like --chroot). A from-scratch rewrite with a focus on the 5% of features that 99% of users use means less code to test and audit. Also a newer codebase that hasn't grown and mutated over the course of 35 years is going to be a lot more focused and easier to reason about.

[1718627440]

> Sudo is [...] old.

This is a take I never understood. I get being huge, but old? Software doesn't age, when it is older it tends to have less bugs, not more.

[gilcot]

Do you mean doas ?

[pepoluan]

doas is too much of a difference from sudo. For instance, it uses a completely different syntax for its config.

sudo-rs is designed to be a drop-in replacement for maybr 95-99% of people who have been using sudo.

(I do use doas on my own systems though)

[tcfhgj]

A good type system can prevent all sorts of logic bugs

[eredengrin]

> People start making sudo more secure by replacing it with sudo-rs

I would have much preferred if ubuntu went with run0 as the default instead of trying to rewrite sudo in rust. I like rust but the approach seems wrong from the beginning to me. The vast majority of sudo usecases are covered in run0 in a much simpler way, and many of the sudo bugs come from the complex configurations it supports (not to mention a poorly configured sudo, which is also a security hazard and quite easy to do). Let people who need sudo install and configure it for themselves, but make something simple the default, especially for a beginner distro like ubuntu.

[pepoluan]

I don't think run0 uses the same configuration syntax as sudo, so it's a no-go from the start.

sudo-rs can be a drop-in replacement for sudo for at least 95-99% of deployments, without any config changes necessary.

Now the rewrite in Rust is important because it greatly prevents appearance of new, memory-based bugs. Which might inadvertently happen if, say because of fixing a logic bug in one of sudo's more complex usages (and thus, less traversed code path), the maintainer introduced a memory bug.

This resistance, IMHO, is moot anyways since the sudo maintainer himself is in support of sudo-rs and actually helped the project in a consultancy capacity (as opposed to directly contributing code).

[eredengrin]

> I don't think run0 uses the same configuration syntax as sudo, so it's a no-go from the start.

This is ubuntu, purportedly targeting ease of use, good defaults, and new Linux users. How many Linux newbies are running with custom sudo configurations? By definition, basically none, and of those who do, it's only for passwordless sudo, which I assume can be trivially recreated in run0. For advanced or enterprise users, it is not difficult to install sudo manually or port their configuration over to run0.

> This resistance, IMHO, is moot anyways since the sudo maintainer himself is in support of sudo-rs and actually helped the project in a consultancy capacity (as opposed to directly contributing code).

I'm not categorically against sudo-rs, but use the tool for the job. If all you need is a simple way to get root privilege, sudo is overkill.

[egorfine]

run0 can f off along with the rest of the systemd abominations. sudo worked for decades perfectly well and didn't call for any replacement. run0, like much of the systemd projects and rust rewrites, is a solution in search of a problem.

[eredengrin]

> sudo worked for decades perfectly well

Yes, if you ignore all the bugs resulting from features that almost nobody uses.

> along with the rest of the systemd abominations

Not too interested in engaging systemd debates. I have enjoyed using systems with and without systemd, and while I understand the arguments against feature creep, I think you'd be throwing the banana out with the peel to overlook the idea behind run0.

For such a security sensitive piece of software like sudo, reducing complexity is one of the best ways to prevent logic bugs (which, as you mentioned in the sibling, is what the above bug was). If run0 can remove a bunch of unused features that are increasing complexity without any benefit, that's a win to me. Or if you don't like systemd, doas on OpenBSD is probably right up your alley with a similar(ish) philosophy.

For anyone who wants to read more about Lennart's reasoning behind run0: https://mastodon.social/@pid_eins/112353324518585654

[egorfine]

I have to reluctantly agree with you on the merit.

However run0 has a property of being a systemd project, which makes it a no go from the inception. And sudo-rs has a similar property of being a virtue signaling project and not a real one. Hence, sudo stays.

> For anyone who wants to read more about Lennart's reasoning

I'm not sure LP is a high-quality source. He has reputation that makes me want to listen to everyone else but him.

[eredengrin]

> I'm not sure LP is a high-quality source. He has reputation that makes me want to listen to everyone else but him.

Based off his reputation, I would agree, but after reading a lot of his own words via blog posts, comments in github issues, etc, I wonder how he gained that reputation. He has solid reasoning behind many of his ideas even if you disagree with them, and his comments seem pretty respectful and focused on the technical aspects. Maybe things were different in the past, or maybe some segments of the community just never forgave him for the early buggy systemd implementations, or maybe I just happened to only read things he wrote when he wasn't having a bad day, who knows.

[egorfine]

Yeah, but he's coming from a viewpoint that is incompatible with the community at large. "Whatever you did in the past was wrong, fuck you and your opinion, that's how it's gonna be".

So, not interested in his opinions even on merit.

[egorfine]

It's a logic bug and has nothing to do with the language it's written in.

[tcfhgj]

A good type system can help reduce the likelihood of logic bugs

[egorfine]

Agree. This is why I like C.

[tcfhgj]

C has barely a type system at all

[egorfine]

On a second though I have to agree with you. I was thinking primitive types compared to JavaScript, but then it hit me.

[secondcoming]

Rewriting old utilities is fine but they have to be backwards compatible.

This is not the same as fixing a bug.

[tracker1]

The "old" version didn't have a test for the feature... the "new" version started with the tests for the "old" version... it was an easy thing to miss as a result.

As other threads have mentioned, a more advanced argument parser and detection of parsed, but unused arguments could have caught this. Of course, there's already complaints about the increase in size for the Rust versions of uutils, mostly offset by a merged binary with separate symlinks. It's a mixed bag.

But, I'm sure you'll be reverting back to Xfree86 now.

[pepoluan]

And how do you define "backwards compatible"?

How can you be sure that something is "backwards compatible"?

By running tests. And as it happens, the original coreutils did not have a test for this particular edge case.

Now that a divergence of behavior has been observed, all parties -- the coreutils devs and the uutils devs -- have agreed that this is an unacceptable regression and created new test cases to prevent the same misbehavior from happening again.

[pclmulqdq]

A lot of database companies go to great lengths to be bug-for-bug compatible with postures. This does happen. It takes some effort, though, which does not appear to have been applied in the case of this rewrite.

[secondcoming]

> And how do you define "backwards compatible"?

Backwards compatible means it's a drop-in replacement.

> How can you be sure that something is "backwards compatible"?

You compare the outputs from the same inputs.

> the original coreutils did not have a test for this particular edge case

So? 'man date' shows this argument option. Just because there was no existing unit test for it doesn't mean it's ok to break it. It would have taken literally 10 seconds to compare the outputs from the old and new program.