Bug 719

Summary:	Should relay SIGHUP when sudo isn't the child of a shell, but doesn't
Product:	Sudo	Reporter:	Peter Cordes <peter>
Component:	Sudo	Assignee:	Todd C. Miller <Todd.Miller>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	low
Version:	1.8.9
Hardware:	PC
OS:	Linux
Attachments:	Diff to relay SIGHUP when not running the command in a pty

Description Peter Cordes 2015-09-11 23:21:49 MDT

xterm -e sudo cmd

When xterm closes, cmd won't receive a SIGHUP.  The same thing happens if you  exec sudo something  from an interactive shell, in an xterm or an ssh session.

workaround:

xterm -e sh -c 'sudo cmd; true'

sh exits on SIGHUP, causing the other processes on the tty to receive SIGHUP.  This is the semantics that sudo assumes.


See http://stackoverflow.com/a/32528498/224132 for a more details, and source for a signal-catching test program.

Comment 1 Peter Cordes 2015-09-11 23:23:11 MDT

Forgot to add, this is on Ubuntu 15.04.  sudo 1.8.9p5-1ubuntu5

$ sudo --version
Sudo version 1.8.9p5
Sudoers policy plugin version 1.8.9p5
Sudoers file grammar version 43
Sudoers I/O plugin version 1.8.9p5

Comment 2 Todd C. Miller 2015-09-15 10:26:01 MDT

Sudo is assuming that the kernel will send SIGUP to the process group associated with the controlling tty and not just the controlling process.  While keyboard-generated signals like SIGINT and SIGQUIT are delivered to all processes in the process group, the same is not true of SIGHUP when the tty is closed.

Comment 3 Todd C. Miller 2015-09-15 10:42:11 MDT

Created attachment 460 [details]
Diff to relay SIGHUP when not running the command in a pty

See also https://www.sudo.ws/repos/sudo/rev/b408a792f31a

Comment 4 Todd C. Miller 2015-11-01 15:25:46 MST

Fixed in sudo 1.8.15