-p/--prompt behaviour breaks ansible

[EvoRowan]

-p on C sudo would replace the entire prompt which ansible relied on for privilege escalation. -p on sudo-rs just appends it within the brackets. With sudo-rs being the default on Ubuntu now, this breaks a lot of ansible scripts.

To Reproduce
$ sudo -p "password:" hostname
[sudo: password:] Password:

Expected behavior
$ sudo -p "password:" hostname
password:

Environment:

• Linux distribution: [Ubuntu 25.10]
• sudo-rs version [0.2.8`]

Additional context
Same behavior happens on 0.2.12 as well

[squell]

Thanks for requesting this. This was a design choice, related issues: #842 and #1242, although this issue is not a duplicate of those.

For our internal discussion it would help to have an example of an ansible script that fails!

[EvoRowan]

Anything that uses become will break, for example:
ansible all -i hosts.yml -m ping --become -K
Just an adhoc command to ping all hosts, but with the --become flag it'll fail

Similarly any task that uses become: true will fail as well

Edit: Just tested with -p "", that works!

[squell]

Related discussion: ansible/ansible#85837, and there's also a fix-in-progress at Ansible: ansible/ansible#86175

Note that regardless of how exactly we would format the string given with --prompt, it will break programs that expect the current sudo prompt (on Linux at least), since we are not hiding the prompt given by PAM(*) (since PAM might be asking for a password, a PIN, ... and we can't control that).

So we can discuss whether the argument given to --prompt fmtstring should be one of these two things:

a. (current) [sudo: {fmtstring}] PAMPrompt:
b. {fmtstring} PAMPrompt:

I.e, so that the default promptvalue is going to be [sudo: authenticate] instead of authenticate. But this will still result in incompatibilities, suppose one would use -p [sudo hash=keykeykey] password: , then with sudo-rs the prompt would become:

[sudo hash=keykeykey] password: Password:

(*) The only exception of course is that if -p "" is given, the whole password prompt is suppressed.

I don't really see a right way forward here except maybe that software should rely less on the exact formatting of the password prompt. We do have plans to modify this in the future (e.g. to mention the hostname by default)

Of course there's also the askpass functionality that we added (and that ogsudo support) that these tools could use for a much more robust password-integration.

Edit: If I read ansible/ansible#85837 correctly, it might be that option b. above might actually pass the ansible code by accident sincce it uses .starts_with. ?

[shallot]

Is there a way to detect non-interactive usage, and apply the backward-compatible default there?

[squell]

Is there a way to detect non-interactive usage, and apply the backward-compatible default there?

Related to the above comment: #1629

Note that I'll modify suggestion b. above by this instead:

b. {fmtstring}, where fmtstring contains a specification (e.g. %P) for the PAM prompt, i.e. the current behaviour would then be achieved using: [sudo: authenticate] %P. The only issue we would need to solve is of course, sudo can also give PAM informational messages or [sudo: input needed] prompts, and those should then also, ideally be served by the SUDO_PROMPT, which would suggest another specifier that could alternatively be ": authenticate" or ": input needed", or "empty". Which would beget something like [sudo%:] %P. (I've used %: as a placeholder)

This would achieve backwards compatibility, but have the downside that if people are using a modified SUDO_PROMPT in conjunction with something like Yubikeys, they would not see the Yubikey prompt.

I still think our present solution is cleaner and suffices as UX choice, though, but just listing this braindrump for future reference.

[squell]

Note: if we change the prompt in the future, Emacs devs have requested that we notify them.