this feels like conflating two goals of why you might want to rewrite something like this in rust.
memory safety (good motivator for rust specifically here)
cleaning up tech debt, learning lessons (not as rust specific)
if you’re naming yourself after an existing project and then tagging that language onto the name as the key differentiator, I feel like you’re implicitly promising not to go too crazy with that second goal. otherwise, why not pick a new name? there are people who might find a new thing that isn’t compatible interesting, but there are way more who will be tolerant of a thing that is just drop in compatible.
I wonder how this could’ve gone if ubuntu had waited until 26.10 to swap in these rust equivalents and then used some of the newer models that we didn’t have last year to do more compatibility testing up front long before an lts release..
Agreed. If you’re distributing a binary, I really don’t see the point of naming a project after the language it’s written in. The right naming precedent would be syslog-ng, which clearly flags the intention to clean house.
I think it there is a time for it, but pretty much only if you’re doing it as a direct port of an existing thing written in a different language with high compatibility expectations, like how the go rewrite of the typescript compiler was called tsgo initially.
To be fair: The sudo-rs project pretty clearly states that it does not aim to cover every feature that sudo has. Their README says so right in the first few lines.
Sudo is under a permissive license, just like the rust port. I fail to see what the license problem is in this case.
The issue I have with the project is that they do nothing to ease transition. e.g. They don't support requiretty and that is good IMHO because that option was never dependable. However instead of parsing it and ignoring it (perhaps with a warning) they instead break on it. If the critique of the option is that it wasn't really doing much then ignoring it won't do much harm. But, much worse, is that they also break on !requiretty. So I'm specifically trying to turn off a feature they don't support and they still break.
Maybe that's not something the upstream project wants to take on but it seems like the kind of patch I want from a vendor like Canonical who are supposed to help me transition between releases smoothly.
I don't think any of this is on the maintainers of sudo-rs per se. It's Canonical's problem to deal with the consequences of shipping a sudo implementation differing substantially from the existing sudo, similarly to how it's Alpine's problem to deal with the effects of using musl as the system libc. Moreso in fact, as Alpine did not previously change the system libc underneath distro users.
My point was sudo-rs works as designed. It might not be a great idea to use it in ubuntu, but the project can probably not do too much about that:-)
I guess I am a bit extreme here, but IMHO a systemd-based distribution should not ship sudo at all anymore -- or only as a wrapper script around run0 and without any promise of compatibility. But then I am just a user/dev on Linux systems and do not need to admin a ton of machines, so I understand that this is probably not going to happen anytime soon :-)
One might go further and insist that if you object to the systemd on the basis of its complexity or ecosystem effects, you would probably also be better served by doas, leaving little reason to use sudo except inertia.
With this in mind, it's puzzling to me why Canonical would replace standard sudo with sudo-rs. My understanding of the change is that Ubuntu's "sudo" command now behaves in meaningfully different ways that it did in the past. This kind of silent changes does not seem desirable, especially not for a program like sudo.
The initial goal of Ubuntu was "Debian for newbies".
Now, let’s be honest: keeping sane on Ubuntu is a nightmare. I installed Ubuntu on my daughter laptop because I thought she would have less problem than Debian. It is a straight LTS Ubuntu. No strange configuration, I even let Snap: well, it is a nightmare.
By default, LibreOffice doesn’t allow her to save documents besides in very strange folders (snap jails). Every upgrade break stuff.
It just not worth it to use Ubuntu. There’s absolutely 0 benefits from using Ubuntu over Debian those days.
Let be honest: Ubuntu was needed 20 years ago. It did a very good job. It improved the ecosystem. But, now, it is just a corporate pile of slimy smelly shit which beg us to put an end to its suffering.
It annoys me so much that they removed -E. I used that all the time. By far the easiest way to run a graphical tool as root is with sudo -E. I don't know what the replacement is even meant to be; are you meant to type out the list of DISPLAY, WAYLAND_DISPLAY, XDG_RUNTIME_DIR, and whatever else I'm forgetting?
Look into Systemd's run0, the motivation for it is basically that exact use case!
[run0] is very useful when you need to run something with privileges but still want all created files and directories to be owned by your current user.
[further down the thread...]
Instead of changing to root, we keep the current uid/gid and instead give it full ambient capabilities
It seems like the intended workflow is to allow list env vars using env_keep in your sudoers file. I tend to agree that allow listing is a much saner default than deny listing.
Does that then mean that the sudo-rs's official position is that Ubuntu should've provided a list of env vars with env_keep?
Because normal users shouldn't be expected to know the ins and out of which exact env vars they need to use to run a program as root. It differs between distros and between desktop environments, and there are many environment variables which you should expose to graphical applications but which many applications will happen to work without. And telling non-technical users that they ought to edit their sudoers file seems like a recipe for disaster in general.
Of all the possible binaries you can choose to break compatibility with, sudo has got to be one of the most important to lamppost the breaking changes on.
Sudo-rs is being actively maintained; features you might expect from original sudo may still be unimplemented or not planned.
Further down, in the section "Differences from original sudo":
• To prevent a common configuration mistake in the sudoers file, wildcards are only supported in argument positions for a command as the final argument. E.g., %sudoers ALL = /sbin/fsck* will allow sudo fsck and sudo fsck_exfat as expected, and %sudoers ALL = /sbin/service ntp * will allow a user to control the ntp service. but %sudoers ALL = /bin/rm *.txt will not allow an operator to run sudo rm README.txt|, nor |sudo rm -rf /home .txt, as with original sudo.
If you find a common use case for original sudo missing, please create a feature request for it in our issue tracker.
To me it reads that there's a bug report for only supporting * as the trailing pattern. Just that change would have made the original use case work:
I haven't filed a bug because we aren't Canonical's free debugging resource
Which feels to me always as "I want to vent my frustration, not a solution". I encounter a lot of people on that frame of mind, because I seek them out to file tickets to the toolchain I maintain. They are generally not receptive to trying to find a fix with their involvement or requests to file tickets, but often enough they are that it is worth it to remind people that filing tickets is how developers find out about things that don't work. Many people have been burned by bad issue trackers and worse reception to filing tickets, so it is an attempt to fight that. Since starting that I have changed a lot of how I deal with my own frustration. I'd like to think that I am now more constructive.
These is an open source project. If filing a ticket is as easy as posting on social media, and you don't, you're not sticking it to the man, you're sticking it to the other users of that software.
As is my qt-webengine based browser that uses the Qt release from eight days ago. As is my Firefox 158.0 that released twenty-one days ago (I'll have to see if it works on 159.0 from seven days ago, or if that's still too out-of-date and suspicious).
lilac | 13 hours ago
this feels like conflating two goals of why you might want to rewrite something like this in rust.
if you’re naming yourself after an existing project and then tagging that language onto the name as the key differentiator, I feel like you’re implicitly promising not to go too crazy with that second goal. otherwise, why not pick a new name? there are people who might find a new thing that isn’t compatible interesting, but there are way more who will be tolerant of a thing that is just drop in compatible.
I wonder how this could’ve gone if ubuntu had waited until 26.10 to swap in these rust equivalents and then used some of the newer models that we didn’t have last year to do more compatibility testing up front long before an lts release..
wrs | 7 hours ago
Agreed. If you’re distributing a binary, I really don’t see the point of naming a project after the language it’s written in. The right naming precedent would be
syslog-ng, which clearly flags the intention to clean house.lilac | 5 hours ago
I think it there is a time for it, but pretty much only if you’re doing it as a direct port of an existing thing written in a different language with high compatibility expectations, like how the go rewrite of the typescript compiler was called tsgo initially.
hunger | 13 hours ago
To be fair: The sudo-rs project pretty clearly states that it does not aim to cover every feature that sudo has. Their README says so right in the first few lines.
Sudo is under a permissive license, just like the rust port. I fail to see what the license problem is in this case.
dvogel | 11 hours ago
The issue I have with the project is that they do nothing to ease transition. e.g. They don't support
requirettyand that is good IMHO because that option was never dependable. However instead of parsing it and ignoring it (perhaps with a warning) they instead break on it. If the critique of the option is that it wasn't really doing much then ignoring it won't do much harm. But, much worse, is that they also break on!requiretty. So I'm specifically trying to turn off a feature they don't support and they still break.Maybe that's not something the upstream project wants to take on but it seems like the kind of patch I want from a vendor like Canonical who are supposed to help me transition between releases smoothly.
ceph | 7 hours ago
I don't think any of this is on the maintainers of sudo-rs per se. It's Canonical's problem to deal with the consequences of shipping a sudo implementation differing substantially from the existing sudo, similarly to how it's Alpine's problem to deal with the effects of using musl as the system libc. Moreso in fact, as Alpine did not previously change the system libc underneath distro users.
hunger | 11 hours ago
My point was sudo-rs works as designed. It might not be a great idea to use it in ubuntu, but the project can probably not do too much about that:-)
I guess I am a bit extreme here, but IMHO a systemd-based distribution should not ship sudo at all anymore -- or only as a wrapper script around run0 and without any promise of compatibility. But then I am just a user/dev on Linux systems and do not need to admin a ton of machines, so I understand that this is probably not going to happen anytime soon :-)
ceph | 6 hours ago
One might go further and insist that if you object to the systemd on the basis of its complexity or ecosystem effects, you would probably also be better served by
doas, leaving little reason to use sudo except inertia.thasso | 9 hours ago
With this in mind, it's puzzling to me why Canonical would replace standard sudo with sudo-rs. My understanding of the change is that Ubuntu's "sudo" command now behaves in meaningfully different ways that it did in the past. This kind of silent changes does not seem desirable, especially not for a program like sudo.
jfloren | 10 hours ago
If they don't actually intend to make it feature complete with sudo, they should name it something else, like sudont, so we know.
ploum | 8 hours ago
I’ve been part of Ubuntu since the very beginning (see https://ploum.net/2024-10-20-20years-linux-desktop-part1.html ).
The initial goal of Ubuntu was "Debian for newbies".
Now, let’s be honest: keeping sane on Ubuntu is a nightmare. I installed Ubuntu on my daughter laptop because I thought she would have less problem than Debian. It is a straight LTS Ubuntu. No strange configuration, I even let Snap: well, it is a nightmare.
By default, LibreOffice doesn’t allow her to save documents besides in very strange folders (snap jails). Every upgrade break stuff.
It just not worth it to use Ubuntu. There’s absolutely 0 benefits from using Ubuntu over Debian those days.
Let be honest: Ubuntu was needed 20 years ago. It did a very good job. It improved the ecosystem. But, now, it is just a corporate pile of slimy smelly shit which beg us to put an end to its suffering.
junot | 6 hours ago
Are newbies expecting regular expressions to work in their /etc/sudoers.d exceptions?
mort | 12 hours ago
It annoys me so much that they removed
-E. I used that all the time. By far the easiest way to run a graphical tool as root is withsudo -E. I don't know what the replacement is even meant to be; are you meant to type out the list of DISPLAY, WAYLAND_DISPLAY, XDG_RUNTIME_DIR, and whatever else I'm forgetting?ThinkChaos | 10 hours ago
Look into Systemd's
run0, the motivation for it is basically that exact use case!https://mastodon.social/@daandemeyer/115565105032166177
kiyurica | 7 hours ago
I wonder why Ubuntu didn't outright switch to run0, the arguably more secure alternative to sudo
mjec | 11 hours ago
If you really want the whole environment, you can do the following. You could even use an alias for it:
(The printf bit is ugly, but the easiest way for me to remove a trailing
\n.)ekuber | 12 hours ago
It seems like the intended workflow is to allow list env vars using
env_keepin your sudoers file. I tend to agree that allow listing is a much saner default than deny listing.https://github.com/trifectatechfoundation/sudo-rs/issues/1299#issuecomment-3421511084
mort | 12 hours ago
Does that then mean that the sudo-rs's official position is that Ubuntu should've provided a list of env vars with
env_keep?Because normal users shouldn't be expected to know the ins and out of which exact env vars they need to use to run a program as root. It differs between distros and between desktop environments, and there are many environment variables which you should expose to graphical applications but which many applications will happen to work without. And telling non-technical users that they ought to edit their sudoers file seems like a recipe for disaster in general.
ekuber | 12 hours ago
I don't know if there is an official position (yet?), but that point was raised in the thread as one of the ways to go.
accelbread | 11 hours ago
Same. https://docs.aws.amazon.com/greengrass/v2/developerguide/greengrass-nucleus-component.html#:~:text=On%20Ubuntu%2025.10%20and%20later%2C%20the%20default
JulianSildenLanglo | 13 hours ago
Of all the possible binaries you can choose to break compatibility with,
sudohas got to be one of the most important to lamppost the breaking changes on.ekuber | 12 hours ago
https://github.com/trifectatechfoundation/sudo-rs/
The first sentence:
Further down, in the section "Differences from original sudo":
To me it reads that there's a bug report for only supporting
*as the trailing pattern. Just that change would have made the original use case work:But
Which feels to me always as "I want to vent my frustration, not a solution". I encounter a lot of people on that frame of mind, because I seek them out to file tickets to the toolchain I maintain. They are generally not receptive to trying to find a fix with their involvement or requests to file tickets, but often enough they are that it is worth it to remind people that filing tickets is how developers find out about things that don't work. Many people have been burned by bad issue trackers and worse reception to filing tickets, so it is an attempt to fight that. Since starting that I have changed a lot of how I deal with my own frustration. I'd like to think that I am now more constructive.
These is an open source project. If filing a ticket is as easy as posting on social media, and you don't, you're not sticking it to the man, you're sticking it to the other users of that software.
invlpg | 11 hours ago
He provides one: switching away from
sudo-rs.johnklos | 9 hours ago
They treat everyone as though we're all too dumb to know what's good for us, and they're taking proactive measures to protect us from ourselves.
What other huge company does that remind us of?
hoistbypetard | 12 hours ago
My fully patched vivaldi is apparently suspicious.
https://l.e42.us/0bcsSWBF
It seems likely that there's a better approach than this.
jackdk | 8 hours ago
I'm sure it's an interesting article but it doesn't like my VPN either.
nytpu | 10 hours ago
As is my qt-webengine based browser that uses the Qt release from eight days ago. As is my Firefox 158.0 that released twenty-one days ago (I'll have to see if it works on 159.0 from seven days ago, or if that's still too out-of-date and suspicious).
nytpu | 10 hours ago
It does block Firefox on Android 159.0 but not desktop Firefox 159.0, what a brilliantly written website.
EDIT: also blocks the latest Chromium 156.0, released fourteen days ago
siru | 5 hours ago
At least it is giving you a clear error message stating that apparently all versions of Vivaldi browser are being blocked on that website.