Closed rajeevvp closed 1 year ago
Does this only happen when sudo prompts for a password or does it always occur?
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.
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.
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.
This is fixed in sudo 1.9.15p2.
Thanks!
sudo-1.9.15
doesn't seem to be restoring the tty settings correctly. Start a newxterm
instance so that you get a new PTY (this is important--if you fix the terminal using a^Jstty sane^J
thensudo
keeps working correctly on the same PTY). Then, if the shell isbash(1)
and with the newsudo
from the latest quarterly:The situation is much worse with
dash(1)
andksh93
. The system/bin/sh
seems OK.