[Bug 2166958] Re: sudo-rs and su-rs alternatives activated without setuid bit set after 24.04 -> 26.04 LTS do-release-upgrade
Fabian Bohrn
2166958 at bugs.launchpad.net
Fri Sep 11 08:38:29 UTC 2026
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
Foundations Bugs, which is subscribed to ubuntu-release-upgrader in
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
Status in rust-sudo-rs package in Ubuntu:
Incomplete
Status in ubuntu-release-upgrader package in Ubuntu:
New
Bug description:
### Impact
After a standard `do-release-upgrade` from Ubuntu 24.04 LTS to 26.04 LTS
("Resolute Raccoon"), the system-wide `sudo` alternative was switched to
sudo-rs, but the target binary was left without the setuid bit set. The
same was true for the su-rs alternative. This makes `sudo` (and `su-rs`)
completely unusable:
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit
set
This effectively locks the admin user out of privileged operations except
via `pkexec`.
### Environment
- Upgrade path: Ubuntu 24.04 LTS (fully patched) -> 26.04 LTS via
`do-release-upgrade`, performed after the 26.04.1 point release
- Architecture: x86_64
- Kernel after upgrade: 7.0.0-31-generic
- sudo-rs / rust-sudo-rs version: 0.2.13-0ubuntu1.2
- sudo (classic) version after upgrade: 1.9.17p2-1ubuntu3
- Fresh installs of 26.04 reportedly get the setuid bit set correctly
(per public documentation/screenshots showing `-rwsr-xr-x` on a fresh
install); this was only observed on an in-place LTS-to-LTS upgrade.
### Steps to reproduce
1. Fully update an Ubuntu 24.04 LTS system (`apt full-upgrade`)
2. `sudo apt install update-manager-core`, then `sudo do-release-upgrade`
3. Let the upgrade complete normally (in this case, several dpkg conffile
prompts were answered "keep local version" for unrelated files —
`/etc/login.defs`, `/etc/ssh/sshd_config`, `/etc/default/grub` — these
should not be relevant to this bug, noted for completeness)
4. Reboot into 26.04 LTS, confirm via `lsb_release -a`
5. Attempt any `sudo` command
### What happened
`sudo` refused to run with:
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit
set
Investigation:
$ readlink -f /usr/bin/sudo
/usr/lib/cargo/bin/sudo
$ ls -l /usr/lib/cargo/bin/sudo
-rwxr-xr-x 1 root root 1090848 Aug 27 10:15 /usr/lib/cargo/bin/sudo
Ownership is correct (root:root), but the setuid bit is missing.
The su-rs binary at the same alternatives-managed path was independently
checked and found to have the identical problem (missing setuid bit),
even though this had gone unnoticed initially because su-rs is not
actively used day-to-day:
$ ls -l /usr/lib/cargo/bin/su
-rwxr-xr-x 1 root root 619808 Aug 27 10:15 /usr/lib/cargo/bin/su
### Timeline from /var/log/dpkg.log (upgrade day)
14:25:55 unpack phase: sudo upgraded 1.9.15p5-3ubuntu5.24.04.2 ->
1.9.17p2-1ubuntu3
14:25:55 install sudo-rs:amd64 <none> -> 0.2.13-0ubuntu1.2
(half-installed -> unpacked)
14:38:05 configure sudo:amd64 1.9.17p2-1ubuntu3 -- completed,
final status "installed" (no error)
14:44:16 configure sudo-rs:amd64 0.2.13-0ubuntu1.2 -- completed,
final status "installed" (no error)
Both postinst runs completed without an error/failure status in
dpkg.log — the scripts did not abort partway through.
### update-alternatives state (post-upgrade, confirmed automatic mode)
$ update-alternatives --display sudo
sudo - auto mode
link best version is /usr/lib/cargo/bin/sudo
link currently points to /usr/lib/cargo/bin/sudo
link sudo is /usr/bin/sudo
/usr/bin/sudo.ws - priority 40
/usr/lib/cargo/bin/sudo - priority 50
sudo-rs (priority 50) correctly outranks sudo.ws (priority 40) in
automatic mode by design — this is expected behavior, not a
misconfiguration on the alternatives side.
### Investigation: postinst logic and a ruled-out theory
The relevant part of `/var/lib/dpkg/info/sudo-rs.postinst`:
set_perms() {
USER=$1
GROUP=$2
MODE=$3
FILE=$4
if ! dpkg-statoverride --list $FILE > /dev/null 2>&1; then
chown $USER:$GROUP $FILE
chmod $MODE $FILE
fi
}
case "$1" in
configure)
set_perms root root 4755 /usr/lib/cargo/bin/sudo
set_perms root root 4755 /usr/lib/cargo/bin/su
mkdir -p /etc/sudoers.d
;;
...
esac
**Initial hypothesis (ruled out):** that a pre-existing `dpkg-statoverride`
entry for these paths, carried over from the 24.04 system, caused the
`chown`/`chmod` branch to be skipped.
This was tested directly and disproven:
$ dpkg-statoverride --list /usr/lib/cargo/bin/sudo
(no output, exit code 1)
No override exists for this file, meaning the `if !
dpkg-statoverride --list ...` condition evaluates true, meaning the
script's own logic *should* have entered the chown/chmod branch and set
the correct permissions. Since dpkg.log shows the configure step
completing successfully with no error status, the chmod call
presumably executed — yet the file was later found without the setuid
bit set.
**Open question / remaining theory (unconfirmed):** something after the
postinst `configure` step ran may have reset the file back to its
default packaged permissions (0755, as shipped in the .deb, since
Debian policy generally disallows shipping setuid bits directly in
archive members). This do-release-upgrade processed a very large
number of packages in one dpkg transaction; whether a later trigger,
re-unpack, or an unrelated maintainer script touched this same file
path afterward has not been established. This report is filed with the
symptom and the ruled-out theory documented, rather than a claimed
root cause, since the actual mechanism is not yet confirmed.
### Workaround
pkexec chmod 4755 /usr/lib/cargo/bin/sudo
pkexec chmod 4755 /usr/lib/cargo/bin/su
(`pkexec` works because PolicyKit authentication is independent of
`sudo`.)
### Additional info
All other setuid binaries on the affected system were checked and found
correct (ownership root:root, setuid bit present): `mount`, `su`
(util-linux, not su-rs), `passwd`, `pkexec`, `sudo.ws`, `fusermount3`,
`ntfs-3g`, `pppd`, `chsh`, `chfn`, `gpasswd`, `newgrp`. Only the two
sudo-rs-package-managed binaries (`sudo`, `su-rs`) were affected,
supporting that this is specific to the sudo-rs postinst/alternatives
path rather than a broader system-wide permissions issue.
---
## Provenance / commands used to gather this report
For reference (not for submission, just so the data trail is traceable
if questions come up later):
| Data point | Command |
|---|---|
| Package versions | `apt-cache policy sudo-rs`, `dpkg -l \| grep -E 'sudo-rs\|^ii sudo '` |
| OS/kernel | `cat /etc/os-release`, `uname -r` |
| Symlink target | `readlink -f /usr/bin/sudo` |
| File permissions | `ls -l /usr/lib/cargo/bin/sudo`, `ls -l /usr/lib/cargo/bin/su` |
| Upgrade timeline | `grep -i sudo /var/log/dpkg.log \| grep '<date>'` |
| Alternatives state | `sudo update-alternatives --display sudo` (run via a still-working privilege path before the fix) |
| Postinst script content | `cat /var/lib/dpkg/info/sudo-rs.postinst` |
| Statoverride check | `dpkg-statoverride --list /usr/lib/cargo/bin/sudo` |
| Broader setuid scan | `find /usr/bin /usr/sbin /usr/lib -perm -4000 -exec ls -l {} \;` |
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rust-sudo-rs/+bug/2166958/+subscriptions
More information about the foundations-bugs
mailing list