sudo-project / sudo

Utility to execute a command as another user
https://www.sudo.ws
Other
1.2k stars 224 forks source link

sudo-1.9.15 fails to restore tty settings on some shells #326

Closed rajeevvp closed 1 year ago

rajeevvp commented 1 year ago

sudo-1.9.15 doesn't seem to be restoring the tty settings correctly. Start a new xterm instance so that you get a new PTY (this is important--if you fix the terminal using a ^Jstty sane^J then sudo keeps working correctly on the same PTY). Then, if the shell is bash(1) and with the new sudo from the latest quarterly:

$ uname -a
FreeBSD x202e 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 GENERIC amd64
$ sudo --version
Sudo version 1.9.15
Sudoers policy plugin version 1.9.15
Sudoers file grammar version 50
Sudoers I/O plugin version 1.9.15
Sudoers audit plugin version 1.9.15
$ echo $BASH_VERSION
5.2.15(0)-release
$ sudo echo hello
Password
hello
$ printf 'hello\nworld\n'                    # type blind because ECHO is off
hello
     world
          $                                  # notice stair-stepped effect. stty(1) indicates raw mode

The situation is much worse with dash(1) and ksh93. The system /bin/sh seems OK.

millert commented 1 year ago

Does this only happen when sudo prompts for a password or does it always occur?

millert commented 1 year ago

Unfortunately I'm unable to reproduce this on FreeBSD 13.2 inside a VM, even from an xterm. Can you try adding the following to /usr/local/etc/sudo.conf?

Debug sudo /var/log/sudo_debug util@debug

and paste the lines between the begin and end of sudo_term_restore_v1? When it is working correctly it should look like:

Nov  8 10:28:23.633 sudo[2200] -> sudo_term_restore_v1 @ ./term.c:152
Nov  8 10:28:23.633 sudo[2200] -> sudo_lock_region_v1 @ ./locking.c:61
Nov  8 10:28:23.633 sudo[2200] sudo_lock_region_v1: lock 14:0
Nov  8 10:28:23.633 sudo[2200] <- sudo_lock_region_v1 @ ./locking.c:101 := true
Nov  8 10:28:23.633 sudo[2200] -> tcsetattr_nobg @ ./term.c:122
Nov  8 10:28:23.633 sudo[2200] <- tcsetattr_nobg @ ./term.c:139 := 0
Nov  8 10:28:23.634 sudo[2200] -> sudo_lock_region_v1 @ ./locking.c:61
Nov  8 10:28:23.634 sudo[2200] sudo_lock_region_v1: unlock 14:0
Nov  8 10:28:23.634 sudo[2200] <- sudo_lock_region_v1 @ ./locking.c:101 := true
Nov  8 10:28:23.634 sudo[2200] <- sudo_term_restore_v1 @ ./term.c:217 := true

I suspect in your case that it is failing and there will also be a line like:

sudo_term_restore_v1: not restoring terminal, c_lflag changed; 0xfoo, expected 0xbar

though it could be c_iflag, c_oflag, c_cflag or c_cc[] that have changed.

rajeevvp commented 1 year ago

OK, I've figured out what's going on here. xterm sets PARENB (parity checking). This is what messes up sudo.

Do stty parenb in a new xterm window, then run sudo to reproduce.

I'll close this issue, as I've got the fix; and I'll ping Tom Dickey about this.

millert commented 1 year ago

This is actually a sudo bug. Sudo is calling tcsetattr() with the TCSASOFT flag which causes c_cflag to be ignored, but then it expects the changed value of c_cflag to be present when it reads it back later.

millert commented 1 year ago

This is fixed in sudo 1.9.15p2.

rajeevvp commented 1 year ago

Thanks!