I don't have a problem with it, specifically. Seems odd that they don't advertise it, though.
It makes me wonder how much is motivated by stuff other than what’s actually the best outcome.
Yeah. I too, hate the Rust Evangelically Orthodox Later Day Christians.
Oh, wait... You're serious. What is religious about rewriting tools in Rust? Isn't that what most programmers do for fun and learning?
Is it any more religious than worshiping Alan Kay or Dijkstra?
> It makes me wonder how much is motivated by stuff other than what’s actually the best outcome.
Looks in the thread... Sees https://www.sudo.ws/security/advisories/
Are you sure the status quo is the better outcome?
"Religious" isn't being used to refer to people rewriting tools in Rust.
It's used to refer to people zealously commenting on message boards that every single tool ever built should be rewritten in Rust, and if you aren't rewriting your tool in Rust, you're an idiot.
Ok, but between me, GP and the article, who said that? Where are the Rabid RIIR fans?
And before you misquote me, I said, why wouldn't you rewrite stuff in Rust, if the status quo is ridden with bugs, and safety issues? And why shouldn't a Linux distro switch to it if they desire.
The person you replied to said: "The religious element of rust programmers seems more extreme than other languages."
You interpreted that in a way that ended up with you asking "What is religious about rewriting tools in Rust".
I clarified that the typical way "religious element of rust programmers" is interpreted is not the act of rewriting tools, but the proselytizing about rust on message boards. I then gave an example of what that proselytizing typically looks like (which was not a claim that you said something like that).
That is the "religious element" being referred to. The proselytizing is the religious element, not the act of rewriting tools in Rust.
(The meme "Rust Evangelists" didn't manifest out of thin air because people hate memory safety or whatever -- it's because people are really, really passionate about Rust, and are vocal about that passion)
But I'm aware that some people are frightened of new languages and paradigms especially if they're 'harder' than what they're used to.
2) the dependency list is tiny
3) it uses a cargo lock, so even if it were using a GitHub dependency, that file keeps a hash of the dependency and points at the specific commit, so if the dependency were to introduce a backdoor it wouldn't be automatically picked up and a commit history rewrite would also fail
https://github.com/trifectatechfoundation/sudo-rs/blob/main/...
I am not frightened. I program in many languages and have no problems grasping Rust concepts. However I find Rust way too opinionated and restricting for personal tastes. For business I can not see myself replacing C++ with Rust unless my paying clients specifically request it. So far not a single one had expressed any interest.
I genuinely hadn't thought of this point of contention beforehand, but oof he did not care for that.
https://distfiles.gentoo.org/releases/amd64/autobuilds/curre...
GNU is nowhere near as dominant in the non-kernel code that people run any longer.
And a lot of the GNU zealots who were particularly interested in getting credit with naming got old.
That killed most of the “user freedom” enthusiasm of the early days. These days, there’s the AGPL, but that’s mostly used like the BSL (“if you want to use AGPL in production, pay us”), than for bootstrapping freedom-respecting compute environments.
If you disagree, show me an AGPL userland that’s appropriate for daily-driving.
I’m slowly migrating off Linux to the BSDs these days. The politics seem less destructive to the user experience with them.
Can't you already do anything you want to GPL code locally?
V3 is incompatible with selling bootloader locked software stacks (pretty much all consumer hardware these days).
Concretely, I can’t do this local thing: Take GPLv3 software, build a board, link the software to vendor blob firmware (~ all current hardware requires this step), flash it to a ROM on the board and sell it to you with a copy of the GPLv3 software’s source code.
I can take the same vendor blob, add a TCP stack, and have your device shell into a copy of GPLv3 software with closed source modifications running in my data center.
This has massive negative consequences for users of GPLv3-reliant IoT crap and cloud services.
Which is great. It prevents enshitification of consumer devices.
By letting cloud services that use GPL software stay closed source it actively encourages development of cloud based tooling in a commercial context and users end up getting forced to sign up with and connect to a closed source cloud service they have even less control over than traditional locally running closed source software.
I think Stallmans motivation for the FSF includes a story about modifying a driver for a printer to support new features. Now imagine if that printer had a cloud based interface and imagine how the GPL would help Stallman add features for a new printer to it. It doesn't, if he wanted to fix the interface he would have to reverse engineer it from scratch. 40 years of FSF and it lets a decades old trend run circles around its goals.
This is why AGPL was invented. You might use my AGPL code in your cloud service, but you need to provide the source code you are running to your clients. You are not allowed to keep any secret sauce secret from your users.
MIT and BSD (and plain GPL) don’t protect users again abuses like this.
It is only "religious" if you think it in such a way.
I'd say the amount of skepticism (rather than valid criticism) has been no less than enthusiam in the community.
As the saying goes, there are two kinds of languages...
I think they just want to ditch GNU tools and lots of young, low level programmers want to use Rust (same rationale for Linus accepting Rust code into the kernel).
Tale as old as time.
https://www.theregister.com/2024/11/08/the_us_government_wan...
Rust is part of a modernized iteration in language design this century
Nobody is calling for Ada code to be rewritten in Rust. But at this point you'd want an argument to choose Ada over Rust when it has become more widespread, especially in open source projects
Here's someone else's take on your question a few years ago: https://news.ycombinator.com/item?id=28347930
- Avionics
- ATM
- Space
- Rail
- Automotive
- Defense
- Security
- Medical
https://www.adacore.com/about-ada
You can find lots of resources here to learn Ada / SPARK: https://learn.adacore.com or just to see what is up. Alternatively, there are good blog posts, too.
For years I used a C window manager I wrote which was less than 150 lines[1], it can definitely be a terse language. But I've also written pretty tight Rust code for a card game engine & its http server. I don't think Rust is particularly more verbose. Rust code can be artistic too[2]
1. https://github.com/serprex/nobox/blob/master/nobox.c
2. https://github.com/serprex/Kelxquoia/blob/master/src/main.rs
https://github.com/serprex/nobox/blob/master/nobox.c is definitely terse. :D I get lost just by looking at it; a little bit of refactoring (indentation-wise) would help though.
In your own comment you mention "actually the best outcome" but that's a matter of politics, doubtless you have different ideas about what "best" would be than I do, and I appreciate that perhaps you've never considered that anybody other than you could be right, but you might want to take a moment to think again.
Everything is political in the same way that everything is offensive and everyone is evil. As in, you're welcome to go around saying that, but don't expect people to find this to be an enlightened perspective.
Isn't not advertising a language the polar opposite of being religious about a language?
I am all for a memory safe sudo and I don't care which language it is written in, use C, Ada, Rust, as long as it is a suitable systems programming language understood by a community of developers and you can proof memory safety to an acceptable degree. If the people first to do it in an such an way happen to use Rust, not accepting that based purely on the language is what would sound religious to me..
Maybe this protectionist reaction (see recent drama within the Linux kernel) is every bit as religiously colored as some people claim Rust people are.
I mean memory safety? What comes next? Not allowing us to use after free like true men would? \s
Tho the extra properties re side channels in said verified code outdoes Rust, so I'd also say it'd be undesirable to replace that C code with Rust
This is why so many Linux developers resists the addition of Rust or C++.
I found an alternative implementation that doesn't rely in being a setuid binary like systemd-run0 much more interesting from a security perspective, but I am no security expert.
I think the main benefit of eliminating setuid binaries is that you can forbid them system-wide (e.g. via mount flags), as a hardening measure.
The original unix process abstraction was extremely simple; the entire spec is a few pages.
The problem is that Linux keeps adding more and more levels of Rube Goldberg machine to its security model, so now literally no one understands how a default minimal install of, say, Ubuntu works.
Adding a magic daemon that runs stuff as root to this pile of complexity probably won’t help. Ripping out almost all the cruft that’s accumulated over the years, and adding back something sane (maybe BSD jails) would work a lot better.
The non-daemon has to parse just as much in addition to making itself secure. Actually it needs to parse more things in more complex ways.
Here’s a simple implementation: https://github.com/TheMilkies/rut/blob/main/rut.c
(Though it doesn’t clear the environment unless I’m missing something - they should probably replace the call to execvp with one to execvpe, and add a null pointer to the end of the argument list).
The problem of setting up root’s environment and parsing the command line is left to the shell in both solutions (the thing I linked doesn’t indirect through a root login shell).
There’s also the config file, but that’s the same for both.
Similarly, the system could be running some SEL derivative or be using a capability system that causes non-standard behavior from system calls, but the daemon has the same problem.
You can enforce a boundary between root and an account that never elevates though. And as far as I understand hardening sudo helps with that.
So stop doing that!
Anybody who finds themselves using sudo is already well off the beaten path, by their own choice. There's nothing wrong with that.
Going back to the topic of the discussion, making sudo more resilient prevents a whole class of possible bugs (see CVE-2021-3156). You may not like sudo, but it is very commonly used to manage access, prevent accidental errors, or improve accountability on Linux servers and workstations. It is not going away. Therefore, improving sudo is a worthwhile goal and a thing to be celebrated.
So does your OS.
I apologize, I do not bookmark these issues, but maybe I should start doing that? In any case, you will find logic bugs which may raise the question "is it really worth the rewrite?".
That’s what 99% of distros default to, and it’s simple.
Here is my doas config:
cat /etc/doas.conf
permit nopass jane as root
Sudo: #ALL ALL = (root) NOPASSWD: C_ZFS
I have no idea what is going here, not sure what ALL means, why root is in (), etc.
> some features of the original sudo will not be implemented in sudo-rs if they serve only highly niche use cases
The Linux port has not been maintained for 3 years. Has unmerged rowhammer fixes and generally a yolo auth system best described as "dangerous". You are better off using a well maintained project, that includes the CVEs^Wwarts.
It's a mistake to think that `doas` on Linux is the same as `doas` on BSD.
If your bar is “I’ll tolerate such crap”, you may as well run your desktop session as root.
run0 does not (and instead relies on systemd).
---
To answer your next question: setuid, while historic, is a bit weird, and is disabled in some environments, e.g. NoNewPrivileges.
Nitpicking, but I thought Android was the most widely deployed Linux OS around...
Idk, just speculating to maybe get the thought process
Linux is not a Unix https://en.wikipedia.org/wiki/Unix-like
There's no "Linux operating system". Linux is the name of the kernel. Android is an operating system, GNU/Linux is, things like BusyBox/Linux are. They're all operating systems that use the Linux kernel.
[1] because it doesn't abstract the hardware platform, doesn't multiplex hardware, nor protect software principals from each other https://www.youtube.com/watch?v=36myc8wQhLo&t=8m48s
Bit like how tomato is technically a fruit but everyone knows that in the context of a supermarket it’s a vegtable
Ubuntu continuously updates itself without permission, killing apps and losing previous state. You have the Javascript based Gnome window manager that is always bugging out. The Ubuntu packages, drivers and kernel are laughably behind Debian and even further behind mainline. Ubuntu continues to morph into something I don't believe in.
That all said, Rust is not a smoking gun for incorrect application logic. It could still happily incorrectly execute stuff with the wrong permissions or blow something up badly. I think it's also a bad idea to offer it as a drop-in replacement when clearly features are still missing since a long time [1].
[1] https://github.com/trifectatechfoundation/sudo-rs/issues?pag...
What? Is this some snap thing because apt sure as hell doesn't do this without you configuring it explicitly.
Somehow "maintainability" has never been something I'd ever associate with Ubuntu. Is it a reference to their source tree? That'd make a lot more sense than if they were referring to the OS itself.
Rotundo•6h ago
stop50•6h ago
XorNot•5h ago
Filligree•5h ago
fluidcruft•4h ago
JoshTriplett•4h ago
> In practice, there are few installations that use sudo-ldap. Most installations that use LDAP as a directory service and sudo have now opted for sssd, sssd-ldap and libsss-sudo.
> The Debian sudo team recommends the use of libsss-sudo for new installations and the migration of existing installations from sudo-ldap to libsss-sudo and sssd.
XorNot•3h ago
dec0dedab0de•4h ago
rnijveld•20m ago
ch_123•4h ago
This makes me wonder:
1) Would a hypothetical "sudo-lite" with these features removed lead to better security without a rewrite?
2) If these features are useful in the real world, will a Rust rewrite of sudo inevitably gain these features over time and end up with similar problems?
throw0101a•4h ago
OpenBSD did this with their doas utility:
* https://en.wikipedia.org/wiki/Doas
Dylan16807•4h ago
0cf8612b2e1e•48m ago
literalAardvark•3h ago
That's not to say that it won't create other ones.
steveklabnik•1h ago
mid-kid•6h ago
[1]: https://www.sudo.ws/security/advisories/
[2]: https://www.sudo.ws/security/advisories/unescape_overflow/
Maxatar•4h ago
https://nvd.nist.gov/vuln/detail/cve-2021-3156