Bugzilla – Bug 568
Regression: suspend / resume of sudo -s (shell)
Last modified: 2012-08-28 18:03:31 MDT
Frequently I use 'sudo -s -u otheruser' to obtain a shell, and then use 'suspend' and 'fg' to switch back and forth. This worked reliably in CentOS 5 (used this for years). Also might be working up to CentOS 6.2 with sudo-1.7.4p5-9.el6_2 (haven't used much) but definitely does NOT work reliably starting with sudo-1.7.4p5-12.el6_2 and was not fixed by the latest sudo-1.7.4p5-13.el6_3 even though the only difference was the patch to exec.c that dealt with suspend/resume (Mercurial rev 3e4e26b79f59). I've also applied the more recent patch to exec_pty.c (670657004784) to the latest RHEL sudo-1.7.4p5-13.el6_3.src.rpm to no effect. I've confirmed the bug still exists in sudo-1.7.9-2.el6.x86_64 and sudo-1.8.5-4.el6.x86_64 RPMs downloaded from sudo.ws. To reproduce: myhost:~> sudo -s -u postgres [sudo] password for myuser: [postgres@myhost myuser]$ suspend Suspended myhost:~> fg sudo -s -u postgres Suspended (tty output) [postgres@myhost myuser]$ [postgres@myhost myuser]$ myhost:~> myhost:~> [at this point the terminal is unusable and must be killed]
I've been unable to reproduce this using the 1.8.4p3 package from sudo.ws: [millert@rh5 ~]$ sudo -V Sudo version 1.8.5p3 Sudoers policy plugin version 1.8.5p3 Sudoers file grammar version 41 Sudoers I/O plugin version 1.8.5p3 [millert@rh5 ~]$ cat /etc/redhat-release CentOS release 5.7 (Final) [millert@rh5 ~]$ sudo -s -u postgres bash-3.2$ id uid=26(postgres) gid=26(postgres) groups=26(postgres) context=user_u:system_r:unconfined_t bash-3.2$ suspend [1]+ Stopped sudo -s -u postgres [millert@rh5 ~]$ fg sudo -s -u postgres bash-3.2$ suspend [1]+ Stopped sudo -s -u postgres [millert@rh5 ~]$ I'll need some more info to help track this down. 1) What shell are you using? I've tested with bash and tcsh without issues. 2) Do you have I/O logging enabled (e.g. log_input or log_output in sudoers)? If not, does the problem go away if you add "Defaults use_pty" to sudoers? 3) Does the problem always occur or just some of the time? If you would try with sudo 1.8.5p3 and an /etc/sudo.conf file with the following line: Debug sudo /var/log/sudo_debug exec@debug and then attach the resulting sudo_debug file to this ticket that would be helpful.
Created attachment 354 [details] sudo_debug during shell suspend Here is debug_log from sudo 1.8.5p3 as I first typed 'sudo -s -u postgres' and then 'suspend', resulting in terminal state corruption.
I attached the output of sudo_debug. The problem DOES GO AWAY with "Defaults use_pty" in sudoers. Should I be using this in general as a workaround? I do not have any I/O logging settings; my sudoers is minimal e.g.: luser ALL=(ALL): ALL Problem exists with both bash and tcsh as the outer shell and inner shell. Problem exists with both CentOS 5 and CentOS 6 by installing the 1.8.5-4 RPMs from sudo.ws. It seemed more of an intermittent thing with CentOS/RHEL RPM sudo-1.7.4p5-9.el6_2.x86_64.rpm but happens every time with sudo-1.7.4p5-13.el6_3.x86_64.rpm. I know the RHEL RPMs include selectively backported patches, so if it would help, I can try installing a few older "clean" versions from sudo.ws to pinpoint when the regression occurred.
Using "Defaults use_pty" should be fine as a workaround. Things are slightly difference when the command is run in its own pty since sudo will proxy the job control signals from the invoking user's pty to the new pty the command is running in. The fact that I don't see the problem you describe means that it is probably a race condition related to delivery of SIGCONT on resume in the non-pty case. I'll look over the debug info which should tell me more.
Please try one of the packages for the sudo 1.8.6 release candidate at http://www.sudo.ws/sudo/dist/beta/packages/index.html When support was added for shells that suspend by doing "kill -STOP $$", a race condition was introduced for more well-behaved shells that restore their process group before actually suspending. In this case, both sudo and the shell will try to change the value of the foreground process group. If the shell does this first, sudo may be killed with SIGTTOU as you saw (since it is no longer the foreground process group). There is a fix for this in sudo 1.8.6. If you could verify that this fixes the problem for you that would be helpful.
Yes!!! You fixed it. I confirmed with 1.8.6rc2-1.el6.x86_64. Great work.