sudo-rs cannot authenticate via stdin when no TTY is present, breaking Ansible (and any tool using `sudo -S`)

Start by reproducing the issue with sudo -v <<< "your-password" without a TTY, then compare the behavior with traditional sudo and the Ansible become command described here. Trace the sudo-rs authentication entry point and existing tests for stdin, TTY, or password handling; done means correct passwords supplied through stdin authenticate successfully without a controlling TTY and the Ansible reproduction succeeds.

Summary

When sudo-rs is the active sudo implementation (via update-alternatives,
as it now is by default on Ubuntu 26.04 LTS), it refuses to authenticate a
password supplied over stdin when no controlling TTY is attached — even
though the traditional sudo package (still installed alongside it) handles
this correctly. This breaks any tool that automates privilege escalation
non-interactively, including Ansible's become mechanism, which is a very
widely used pattern.

Steps to reproduce

1. On a system where sudo-rs is the active sudo alternative, attempt to
   authenticate with a password piped over stdin and no TTY:

   sudo -v <<< "your-password"
   

2. Observe the failure:

   sudo: A terminal is required to authenticate
   

3. Switch to traditional sudo and repeat the identical command:

   sudo update-alternatives --set sudo /usr/bin/sudo.ws
   sudo -v <<< "your-password"
   

4. This succeeds silently (exit 0, timestamp cached) — identical stdin,
   identical password, only the sudo implementation changed.

Ansible-specific reproduction (the real-world trigger)

ansible localhost -c local -b -m command -a whoami -e ansible_become_pass=your-password

With sudo-rs active:

[ERROR]: Task failed: Timed out waiting for become success or become password prompt.
>>> Standard Error
[sudo: [sudo via ansible, key=<redacted>] password:] Password:

With traditional sudo active (only variable changed): CHANGED | rc=0 >> root

Expected behavior

sudo -S-style non-interactive authentication (password supplied via stdin,
no TTY) should succeed when the password is correct, matching traditional
sudo's behavior, since sudo-rs is documented as a drop-in replacement with
compatible sudoers/PAM handling.

Actual behavior

sudo-rs unconditionally requires a real TTY to authenticate and rejects
stdin-supplied credentials with sudo: A terminal is required to authenticate, regardless of whether the password is correct. This silently
breaks any automation (Ansible, and likely other config-management/CI tools
using the same sudo -S convention) the moment sudo-rs becomes the active
sudo — which, as of Ubuntu 26.04 LTS, is the out-of-the-box default.

Environment

• OS: Kubuntu 26.04 LTS
• sudo-rs version: 0.2.13-0ubuntu1
• sudo (traditional) version, installed side by side: 1.9.17p2-1ubuntu3
• ansible-core version: reproduced identically on both 2.20.1 (the
  distro package) and 2.19.12 (via pipx) — ruling out ansible-core as the
  cause
• update-alternatives for sudo defaults to the sudo-rs binary
  (/usr/lib/cargo/bin/sudo, priority 50) over traditional sudo
  (/usr/bin/sudo.ws, priority 40)

Additional context

Impact

Because Ubuntu 26.04 LTS ships sudo-rs at a higher update-alternatives
priority than traditional sudo by default, this breaks Ansible provisioning
(and presumably other automation) on a stock fresh install, with no error
message pointing at the actual cause — the failure surfaces as an opaque
timeout deep inside the automation tool, not as a sudo-rs error. Given how
common sudo -S-based automation is, this seems likely to affect a lot of
people upgrading/reinstalling to 26.04 without realizing why their existing
playbooks/scripts suddenly hang.