Sudo-rs enables pwfeedback by default for Resolute Raccoon

February 27, 2026, 2:18pm 1

Hi there folks! I hope you all are doing well. This is a small update to notify you of a new behavioral change coming to sudo-rs for Resolute Raccoon, as we have seen some users react to it already on the development branch.

Background

Last year, a proposal was made upstream to enable the sudoers option “pwfeedback” by default for sudo-rs (see issue #1300). This means that when using sudo, an asterisk will be printed for each input character. After some discussion it was recently decided that the benefits of this change outweighed the potential risks and it was consequently merged. Below are some of the points considered.

Benefits:

• sudo is the default way to become root on Ubuntu and running it may be the first time many new users encounter a program that disables echo for password entry. (Paraphrased from Todd Miller’s comment)

• Echoing bullets or asterisks is consistent with the behavior of many other modern password prompts.

• Receiving visual feedback to user input helps mitigate typing errors.

Risk 1:

A threat actor observing the prompt may infer the input password length.

Justification:

1. Observing the password requires the threat actor to either be physically present or that the user voluntarily shares their screen output remotely. If physically present, there are more immediate risks associated with a threat actor observing the user, such as being able to observe the physical keyboard itself as the password is being typed. If sharing screen output remotely, the user is aware that someone else is watching and can as such take appropriate precautions in response (such as turning off pwfeedback if necessary).

2. Knowing the password length does not meaningfully reduce the password search space if the password is significantly long (minimum 16 characters), uses a mixture of characters, and generally follows best practices for a secure password. Consider this:

A password can contain 95 different printable ASCII characters. For a password of 16 characters, this theoretically means that there are roughly 4.4 * 10^31 different passwords, whereas there are roughly 4.7 * 10^29 passwords of length 15 or below. Effectively, the number of possible passwords of length 15 or below is roughly 1 % of the number of passwords with exactly 16 characters.

Risk 2:

Test-suites strictly scanning the password input prompt may break if they only expect a newline character being output.

Fix:

While this should not affect most, some users may have test-suites strictly scanning the terminal output. This can be solved by either disabling pwfeedback (see How do I revert this change?), or by adjusting the test to not consider this variable part of the command-line.

How do I revert this change?

While we hope this will be a helpful change for most, we understand that some of you may be against this default change. After all, sudo has always historically not echoed the input. For those of you who do not want this behavior, it can be reverted by performing the following.

1. Edit the sudoers configuration file:

   $ sudo visudo
   

2. Add the following option:

   Defaults !pwfeedback
   

Thank you for using Ubuntu and all the best,

Simon Johnsson

That’s a good idea! Let me check that out. The problem with having it explicitly enabled in /etc/sudoers is that the file is shared with sudo.ws, so mentioning the sudo-rs behavior while still having it commented out is probably the best option in that case.

Edit: I created a bug on Launchpad to keep track of the suggestion (LP: #2142864)

I’m not opposed to the change, but I am opposed to inconsistency in a user interface and, unfortunately, with this change there’s now several bits of inconsistency in the interface I encountered while testing recent Pi server images:

login

The terminal login (from /usr/bin/login via /usr/bin/agetty) still doesn’t echo anything during password entry. Unfortunately, I don’t see an option or configuration item to enable this in /usr/bin/login.

systemd

A systemctl command that requires elevated privileges will also prompt for a password if not run with sudo. For example, running systemctl daemon-reload as the default ubuntu user will prompt for a password. This also does not echo anything. It appears there is a setting to change this for systemd-ask-password, but that’s a boot time application intended for system-wide password entry. I haven’t found an equivalent for systemctl operations but I’m more hopeful there may be an option hiding somewhere.

I suspect the login problem is “too late to fix” at this stage: there’s no configuration option, I doubt we want to go patching something critical like login, and if there were a more modern alternative that did allow such configuration it’s too late to MIR (and would probably break a whole pile of tests, anyway). It’s possible the systemd side might be trivial, if the right configuration switch can be found. But overall, I’d suggest these are things to ponder for the release after resolute.