Sudo-rs is now default for Questing Quokka

ravi-sharma · September 2, 2025, 11:37am

Hello, this is a quick update following the announcement of adopting sudo-rs as default in Ubuntu.

Throughout this article, I will use sudo.ws to refer to the OG sudo and sudo-rs to refer to the reimagining and rust implementation by the Trifecta Tech Foundation . I will use sudo to refer to the general concept of sudo.

sudo-rs 0.2.8 is now the default sudo in Ubuntu daily images . Upstream sudo-rs team did a fantastic job to implement all the necessary features in time for 25.10 Feature Freeze. This release includes support for older Linux kernels < 5.9, sudoedit, support for NOEXEC and AppArmor profile switching, along with various miscellaneous fixes.

On the packaging side,

sudo-rs successfully passed the main inclusion review.
sudo-rs 0.2.8-1ubuntu2 is the latest version in the main archive as of today.
It includes vendored rust dependencies.
i386 build has been enabled, although it does not have manpages since no one is expected to use it interactively.
It has been added to platform seeds.
It is part of the Ubuntu Minimal base system and cannot be removed from the system.

The job is not done,

Some integration tests have implicit dependency on sudo, there are cases where these test cases fail because they rely on feature from sudo.ws which is either not implemented or behaves differently in sudo-rs. Eg. sudo.ws passport prompt. Please watch out for these and report them here or on matrix #devel:ubuntu.com.
There will be another release with bug fixes and some post 0.2.8 patches from upstream. Example remove documentation for the ignored ‘-I’, ‘-q’, ‘-s’ flags
We need to plan for 26.10 when sudo-rs is the only sudo provider in the main archive. To achieve this, sudo-rs will need to ship /etc/sudoers config and not depend upon sudo.ws to provide one (lp-report). sudo-rs will also need to declare Conflict on sudo.ws to ensure that there is only one Provider of sudo on the system.

Once again, sudo-rs is not a perfect in-place replacement for sudo.ws. If you’d like to look at the differences, I suggest the following links.

Additionally, I/O logging and sudoreplay is not supported. There is no sudoers.ldap, LDAP authentication via PAM should work. As a consequence, we have also removed the sudo.ws sudo-ldap package from Questing. Some of these features are also being removed from Debian. Please look at the CLI flags parity with sudo.ws, although the definitive list is always available via sudo-rs --help. Running man sudoers will also show the configuration options supported by sudo-rs.

sudo-rs package also includes su-rs, a reimplementation of su from util-linux. Users of Ubuntu should continue to use /usr/bin/su, but are also encouraged to experiment with su-rs. The possibility of replacing su with su-rs will be evaluated in a future development cycle

When things go wrong

In case something goes wrong and the /usr/bin/sudo symlink is not available, you should be able to use /usr/bin/sudo-rs (full path: /usr/lib/cargo/bin/sudo). sudo.ws, along with its related binaries is available as well - /usr/bin/sudo.ws, /usr/sbin/visudo.ws, /usr/bin/sudoreplay.ws.

If you’d like to switch to the previous sudo (sudo.ws) and not use sudo-rs, you can use the alternatives mechanism to switch.
This is not recommended, but if you really need to, here are the steps:

Interactive

# update-alternatives --config sudo

Non-interactive

# update-alternatives --set sudo /usr/bin/sudo.ws

You can always switch back to sudo-rs using
# update-alternatives --set sudo /usr/lib/cargo/bin/sudo

Please test the daily image or wait for the next snapshot.

PS: If you miss sudo.ws insults, try this project.

corradoventu · September 2, 2025, 12:26pm

well, but now please fix bug +bug/2120249

ravi-sharma · September 2, 2025, 12:57pm

Thanks, I am on it. I discussed this a bit on matrix devel channel. I’ll send a proposal to ubuntu-devel mailing list.

rurban · September 2, 2025, 4:42pm

Eg. sudo.ws passport prompt.

I doubt that both sudo’s can prompt for your passport. Maybe you meant password, but it really is the missing use_pty detection

ravi-sharma · September 3, 2025, 9:06am

rurban, welcome to the community.

I doubt that both sudo’s can prompt for your passport.

Are you sure we don’t want to age check users before elevating their privileges?

but it really is the missing use_pty detection

Could you please file a bug? I see these which could be related

venefilyn · September 4, 2025, 1:59pm

For the record, until sudo-rs supports --askpass Cockpit will not work. Jelle from our team is gonna file a bug about it so it’s tracked.

YamiYukiSenpai · September 4, 2025, 9:25pm

Hopefully that’s fixed by 26.04

Otherwise, gonna revert all of my sudo to use the classic version on my servers

totto164 · October 9, 2025, 3:07pm

I am a long-standing Ubuntu user and use sudo and coreutils in scripts a lot, and I have nothing against rust per sè, but its just too early IMO. I read about the switch to sudo-rs and thought, how bad can it be, it surely supports all the features, if a ‘large’ distro like Ubuntu uses it in their release. But just running “sudo apt-get update” revealed some things the “new” sudo doesn’t support. e.g.

/etc/sudoers.d/jellyfin-sudoers:23:30: unknown setting: 'requiretty'
Defaults!RESTARTSERVER_SYSV !requiretty
                             ^~~~~~~~~~
/etc/sudoers:68:34: expected nonnegative number
Defaults:<my_username> timestamp_timeout=-1
                                 ^
/etc/sudoers:75:16: unknown setting: 'timestamp_type'
Defaults:<my_username> timestamp_type=global

All these things were well-supported by the “normal” sudo and this just happened in the first command I run after the update to 25.10, how many more of these incompatibilities do the rust variants have. So Tl.dr. IMO, it’s just TOO EARLY.

ravi-sharma · October 9, 2025, 4:08pm

totto164, welcome to the community.

The aim of the project is not to support all sudo.ws features. Here are the upstream reports for the issue you encountered, you will at least find the reason for not supporting the sudoers setting and possibly a workaround.

fprietog · October 10, 2025, 8:17pm

I’ve switched back to sudo. This is what happens every time I use a sudo-rs:

/etc/sudoers:11:17: unknown setting: 'mailto'
Defaults        mailto="f*******@*******.com,f*******@*******.com"
                ^~~~~~
[sudo: authenticate] Password:

And I saw this note in the readme of the sudo-rs github project:
* sudo-rs will not include the sendmail support of original sudo.

I understand that the new sudo-rs will never inform to admin email when an user try to use it and fails. To me it’s a step back in security (I know I can check logs and that but this is really handy).

BTW, the ******* are written by me. The sudo-rs discloses the admins emails in sudoers file to any user that try sudo. Really clever!

max-illis · October 11, 2025, 8:18am

I have the same issue, but its not clear to me what the fix is… Should I just go back to the ‘old’ sudo alternative?

sudo apt update && apt list --upgradable
/etc/sudoers.d/jellyfin-sudoers:23:30: unknown setting: 'requiretty'
Defaults!RESTARTSERVER_SYSV !requiretty
                             ^~~~~~~~~~
/etc/sudoers.d/jellyfin-sudoers:24:28: unknown setting: 'requiretty'
Defaults!STARTSERVER_SYSV !requiretty
                           ^~~~~~~~~~
/etc/sudoers.d/jellyfin-sudoers:25:27: unknown setting: 'requiretty'
Defaults!STOPSERVER_SYSV !requiretty
                          ^~~~~~~~~~
/etc/sudoers.d/jellyfin-sudoers:26:33: unknown setting: 'requiretty'
Defaults!RESTARTSERVER_SYSTEMD !requiretty
                                ^~~~~~~~~~
/etc/sudoers.d/jellyfin-sudoers:27:31: unknown setting: 'requiretty'
Defaults!STARTSERVER_SYSTEMD !requiretty
                              ^~~~~~~~~~
/etc/sudoers.d/jellyfin-sudoers:28:30: unknown setting: 'requiretty'
Defaults!STOPSERVER_SYSTEMD !requiretty
                             ^~~~~~~~~~
/etc/sudoers.d/jellyfin-sudoers:29:31: unknown setting: 'requiretty'
Defaults!RESTARTSERVER_INITD !requiretty
                              ^~~~~~~~~~
/etc/sudoers.d/jellyfin-sudoers:30:29: unknown setting: 'requiretty'
Defaults!STARTSERVER_INITD !requiretty
                            ^~~~~~~~~~
/etc/sudoers.d/jellyfin-sudoers:31:28: unknown setting: 'requiretty'
Defaults!STOPSERVER_INITD !requiretty
                           ^~~~~~~~~~
/etc/sudoers.d/jellyfin-sudoers:37:20: unknown setting: 'requiretty'
Defaults:jellyfin !requiretty
                   ^~~~~~~~~~
[sudo: authenticate] Password:

ravi-sharma · October 13, 2025, 8:50am

max-ills, welcome to the community.

requiretty is off by default in sudo-rs and sudo.ws (see man sudoers). You can ignore the error or remove !requiretty from your config. The unknown setting error will be removed in a future release of sudo-rs Add possibility in `defaults/settings_dsl` for "deprecated" features. · Issue #1253 · trifectatechfoundation/sudo-rs · GitHub.