Bug 1056

Repro testcase using ssh and expect since this was the easiest way I found to muck around with PTYs:

#! /usr/bin/env expect -f
spawn ssh -t delroth@myhost "exec <\$SSH_TTY >\$SSH_TTY 2>/dev/tty0; echo ssh_tty: \$SSH_TTY; sudo -u nginx sudo -n -u root true || echo end"
expect "end"

Where delroth@myhost is a user which can use sudo NOPASSWD (so the outer sudo invocation works) but nginx@myhost is a user which cannot use sudo (so the inner sudo invocation fails).

Output:
spawn ssh -t delroth@sunny exec <$SSH_TTY >$SSH_TTY 2>/dev/tty0; echo ssh_tty: $SSH_TTY; sudo -u nginx sudo -n -u root true || echo end
ssh_tty: /dev/pts/1
sudo: a password is required
end

As you can see, $SSH_TTY is /dev/pts/1, which is not /dev/tty0. stderr is redirected to /dev/tty0, but "sudo: a password is required" still shows up on /dev/pts/1.

This happens only in very specific situations. Things that don't trigger the same issue:
- Redirecting stderr to a file instead of another TTY/PTY.
- Redirecting stderr to /dev/null.
- Not nesting sudo.

This was originally discovered by the NixOS integration test suite for sudo when attempting to update to 1.9.14. The integration test runner splits stdout and stderr into two separate virtual (qemu) TTY devices, and the tests started failing on 1.9.14 because stderr unexpectedly showed up on stdout. https://github.com/NixOS/nixpkgs/pull/240681

(This is likely not a new issue in 1.9.14, but use_pty wasn't the default before. I have not tried to bisect this.)