Hi Simon, Quick follow-up with what I found after digging further, plus an important correction to avoid sending you down the wrong path.
**Workaround adopted** Given the fragility described below, I've switched the system's active `sudo` alternative back to classic sudo (`sudo.ws`, priority 40) via `update-alternatives --config sudo`, rather than staying on sudo-rs. Noting this here in case it's useful data point for how people are working around this in practice. **Important disambiguation — a second "setuid missing" failure was NOT a recurrence of this bug** After the original report, `sudo` failed again with the same "must be owned by uid 0 and have the setuid bit set" message, later, completely unrelated to any upgrade or package operation. I initially assumed this was the same rust-sudo-rs postinst issue recurring spontaneously — but tracing it back, it wasn't. Separately from this bug, I had (with the benefit of hindsight, mistakenly) run a recursive `chown root:root` across `/usr/share` and `/usr/lib` on this system, to correct an unrelated ownership problem in those trees (traced to a third-party vendor installer that had chowned parts of `/usr` to a regular user weeks earlier). `/usr/lib/cargo/bin/sudo` sits inside that tree. `chown()` strips the setuid bit as a kernel-level side effect on any ownership change, regardless of the resulting owner — so my own "fix" for the unrelated ownership issue silently re-stripped sudo-rs's setuid bit a second time. Nothing to do with rust-sudo-rs's packaging. I'm flagging this explicitly so this second incident doesn't get treated as evidence of a recurring/intermittent packaging bug — it was self-inflicted, on my end, by an unrelated operation. **What this incident did surface, though** While tracing that second failure, I found the same `chown -R` had also silently stripped the setuid bit from `/usr/lib/dbus-1.0/dbus-daemon-launch-helper` (fixed via `apt install --reinstall dbus`) and corrupted the capability set on `/usr/lib/snapd/snap-confine` (fixed by re-running `setcap` against the packaged `/usr/lib/snapd/snap-confine.caps` file), both of which caused separate, unrelated-looking failures (D-Bus system service activation failing with `Permission denied`, and snap apps failing to launch with a `capset`/E2BIG-style error). A full system scan afterward (`find / -xdev \( -perm -4000 -o -perm -2000 \)`) came back clean against the expected baseline. I mention this only as context, not as something for this bug specifically — it's a good illustration of how disruptive a stray `chown -R` on `/usr` can be across unrelated subsystems, but it's not an rust-sudo-rs issue. **Where this leaves the original report** The original finding stands as reported: sudo-rs's postinst left the setuid bit unset after the 24.04→26.04 do-release-upgrade, with no dpkg-statoverride override present, no visible postinst error, and no other process touching the file afterward per the sanitized dist-upgrade logs I sent over. I don't have anything new that explains *that* original occurrence — the dbus/snap-confine/second-sudo-rs findings above are a separate, self-inflicted incident on my system, not additional evidence for the upgrade-time bug itself. Happy to run anything else that would help narrow down the original postinst behavior. For transparency: I worked through this investigation (including the log analysis and the disambiguation above) together with Claude Sonnet 5, Anthropic's AI assistant, as a debugging aid. Flagging that in case it's useful context — the findings themselves are what matter, and I'm happy to verify or re-run anything manually if that would help. Best, foxtocks -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2166958 Title: sudo-rs and su-rs alternatives activated without setuid bit set after 24.04 -> 26.04 LTS do-release-upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rust-sudo-rs/+bug/2166958/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
