Public bug reported:
### 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 {} \;` |
** Affects: rust-sudo-rs (Ubuntu)
Importance: Undecided
Status: New
--
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
