Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
rajeevvp opened this issue Nov 8, 2023 · 6 comments
Closed

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

rajeevvp opened this issue Nov 8, 2023 · 6 comments

Comments

@rajeevvp
Copy link

rajeevvp commented Nov 8, 2023

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
Copy link
Collaborator

millert commented Nov 8, 2023

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

@millert
Copy link
Collaborator

millert commented Nov 8, 2023

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
Copy link
Author

rajeevvp commented Nov 8, 2023

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.

@rajeevvp rajeevvp closed this as completed Nov 8, 2023
@millert
Copy link
Collaborator

millert commented Nov 8, 2023

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 added a commit that referenced this issue Nov 9, 2023
If TCSASOFT is present, tcsetattr() will ignore c_cflag.
Fixes a bug where sudo_term_restore() would refuse to change
the terminal settings back if the PARENB control flag was set.
GitHub issue #326.
@millert
Copy link
Collaborator

millert commented Nov 9, 2023

This is fixed in sudo 1.9.15p2.

@rajeevvp
Copy link
Author

rajeevvp commented Nov 9, 2023

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants