The Ubuntu 26.04 Rust sudo is not compatible with standard sudo
20 points by twp
20 points by twp
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..
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.
https://github.com/trifectatechfoundation/sudo-rs/
The first sentence:
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 allowsudo fsckandsudo fsck_exfatas expected, and%sudoers ALL = /sbin/service ntp *will allow a user to control thentpservice. but%sudoers ALL = /bin/rm *.txtwill not allow an operator to runsudo 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:
%corestaff ALL=NOPASSWD: /usr/bin/mailq "", \
/usr/sbin/exim -bp, \
/usr/sbin/exim -bp[acru]
But
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.
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 locense 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.
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?
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.
https://github.com/trifectatechfoundation/sudo-rs/issues/1299#issuecomment-3421511084
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.
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.
If you really want the whole environment, you can do the following. You could even use an alias for it:
sudo --preserve-env="$(printf "%s" "$(env | cut -d= -f1)" | tr '\n' ',')"
(The printf bit is ugly, but the easiest way for me to remove a trailing \n.)
My fully patched vivaldi is apparently suspicious.
It seems likely that there's a better approach than this.