PAM_TTY is not properly computed and exposed in situations where it could

[3v1n0]

Describe the bug

PAM_TTY is not properly computed by sudo-rs when input redirection or IO streams are unset or closed.

To Reproduce

With this minimal reproducer (that simulates what sshuttle does):

#!/usr/bin/env python3

import shutil
import socket
import subprocess
import sys

def main() -> int:
    sudo = shutil.which("sudo") or "sudo"
    #sudo = "/home/user-sudo/sudo"
    sudo = "/usr/lib/cargo/bin/sudo"
    #sudo = "/usr/bin/sudo.ws"
    cmd = [sudo, "-p", "[local sudo] Password: ", "id"]

    s1, s2 = socket.socketpair()

    def setup() -> None:
        s2.close()

    proc = subprocess.Popen(cmd, stdin=subprocess.DEVNULL, stdout=s1, preexec_fn=setup)
    s1.close()

    output = s2.makefile("rb").read()
    if output:
        sys.stdout.buffer.write(output)

    rc = proc.wait()
    s2.close()
    return rc

if __name__ == "__main__":
    raise SystemExit(main())

Modify /etc/pam.d/sudo so that it contains:

  auth optional pam_exec.so stdout /usr/bin/env

Expected behavior

PAM_SERVICE=sudo
PAM_USER=user-sudo
PAM_TTY=/dev/pts/1
PAM_RUSER=user-sudo
PAM_TYPE=auth

Actual behavior

PAM_SERVICE=sudo
PAM_USER=user-sudo
PAM_RUSER=user-sudo
PAM_TYPE=auth

So PAM_TTY is missing, even though we are in a terminal. This may make PAM modules not to properly handle things in the right way, and in particular authd will not run the right client for the conversation.

See also canonical/authd#901
Also related to #1260