From c2eee7904dfc698ae887279791d81600e4c0a7ca Mon Sep 17 00:00:00 2001 From: "Todd C. Miller" Date: Fri, 1 Dec 2017 13:53:09 -0700 Subject: [PATCH] Background processes started by the command will no longer receive SIGHUP. --- doc/sudo.cat | 34 ++++++++++++---------------------- doc/sudo.man.in | 34 ++++++++-------------------------- doc/sudo.mdoc.in | 32 +++++++------------------------- 3 files changed, 27 insertions(+), 73 deletions(-) diff --git a/doc/sudo.cat b/doc/sudo.cat index ebec2753a..743a785e5 100644 --- a/doc/sudo.cat +++ b/doc/sudo.cat @@ -401,30 +401,20 @@ CCOOMMMMAANNDD EEXXEECCUUTTIIOONN POSIX terms an "orphaned process group" and it would not receive any job control signals from the kernel. When the command exits or is terminated by a signal, the _m_o_n_i_t_o_r passes the command's exit status to the main - ssuuddoo process and exits. On most systems, processes created by the - command that are still running in the background when the command exits - and that have not changed their session will receive the SIGHUP signal - when the monitor exits, since it is the terminal session leader. To - prevent this from happening, background processes started by the command - can be invoked via the nohup(1) command to ignore SIGHUP. Alternately, - some systems provide a setsid(1) command which can be used to run the - command in a new session. In both cases, there is a potential race - condition where the command being run via ssuuddoo could exit before nohup(1) - or setsid(1) have time to complete their setup. + ssuuddoo process and exits. After receiving the command's exit status, the + main ssuuddoo passes the command's exit status to the security policy's close + function and exits. If no pty is used, ssuuddoo calls fork(2), sets up the execution environment as described above, and uses the execve(2) system call to run the command - in the child process. - - In both cases, the main ssuuddoo process waits until the command (or monitor) - has completed, then passes the command's exit status to the security - policy's close function and exits. As a special case, if the policy - plugin does not define a close function and no pty is required, ssuuddoo will - execute the command directly instead of calling fork(2) first. The - _s_u_d_o_e_r_s policy plugin will only define a close function when I/O logging - is enabled, a pty is required, or the _p_a_m___s_e_s_s_i_o_n or _p_a_m___s_e_t_c_r_e_d options - are enabled. Note that _p_a_m___s_e_s_s_i_o_n and _p_a_m___s_e_t_c_r_e_d are enabled by - default on systems using PAM. + in the child process. The main ssuuddoo process waits until the command has + completed, then passes the command's exit status to the security policy's + close function and exits. As a special case, if the policy plugin does + not define a close function, ssuuddoo will execute the command directly + instead of calling fork(2) first. The _s_u_d_o_e_r_s policy plugin will only + define a close function when I/O logging is enabled, a pty is required, + or the _p_a_m___s_e_s_s_i_o_n or _p_a_m___s_e_t_c_r_e_d options are enabled. Note that + _p_a_m___s_e_s_s_i_o_n and _p_a_m___s_e_t_c_r_e_d are enabled by default on systems using PAM. SSiiggnnaall hhaannddlliinngg When the command is run as a child of the ssuuddoo process, ssuuddoo will relay @@ -665,4 +655,4 @@ DDIISSCCLLAAIIMMEERR file distributed with ssuuddoo or https://www.sudo.ws/license.html for complete details. -Sudo 1.8.21 November 29, 2017 Sudo 1.8.21 +Sudo 1.8.21 December 1, 2017 Sudo 1.8.21 diff --git a/doc/sudo.man.in b/doc/sudo.man.in index 2b8928819..fe1093be9 100644 --- a/doc/sudo.man.in +++ b/doc/sudo.man.in @@ -21,7 +21,7 @@ .\" Agency (DARPA) and Air Force Research Laboratory, Air Force .\" Materiel Command, USAF, under agreement number F39502-99-1-0512. .\" -.TH "SUDO" "8" "November 29, 2017" "Sudo @PACKAGE_VERSION@" "System Manager's Manual" +.TH "SUDO" "8" "December 1, 2017" "Sudo @PACKAGE_VERSION@" "System Manager's Manual" .nh .if n .ad l .SH "NAME" @@ -756,27 +756,10 @@ When the command exits or is terminated by a signal, the passes the command's exit status to the main \fBsudo\fR process and exits. -On most systems, processes created by the command that are still -running in the background when the command exits and that have -not changed their session will receive the -\fRSIGHUP\fR -signal when the monitor exits, since it is the terminal session leader. -To prevent this from happening, background processes started by the command -can be invoked via the -nohup(1) -command to ignore -\fRSIGHUP\fR. -Alternately, some systems provide a -setsid(1) -command which can be used to run the command in a new session. -In both cases, there is a potential race condition where the -command being run via -\fBsudo\fR -could exit before -nohup(1) -or -setsid(1) -have time to complete their setup. +After receiving the command's exit status, the main +\fBsudo\fR +passes the command's exit status to the security policy's close function +and exits. .PP If no pty is used, \fBsudo\fR @@ -785,13 +768,12 @@ fork(2), sets up the execution environment as described above, and uses the execve(2) system call to run the command in the child process. -.PP -In both cases, the main +The main \fBsudo\fR -process waits until the command (or monitor) has completed, then passes the +process waits until the command has completed, then passes the command's exit status to the security policy's close function and exits. As a special case, if the policy plugin does not define a close -function and no pty is required, +function, \fBsudo\fR will execute the command directly instead of calling fork(2) diff --git a/doc/sudo.mdoc.in b/doc/sudo.mdoc.in index d4b6b0f9e..f512cfaf4 100644 --- a/doc/sudo.mdoc.in +++ b/doc/sudo.mdoc.in @@ -19,7 +19,7 @@ .\" Agency (DARPA) and Air Force Research Laboratory, Air Force .\" Materiel Command, USAF, under agreement number F39502-99-1-0512. .\" -.Dd November 29, 2017 +.Dd December 1, 2017 .Dt SUDO @mansectsu@ .Os Sudo @PACKAGE_VERSION@ .Sh NAME @@ -685,27 +685,10 @@ When the command exits or is terminated by a signal, the passes the command's exit status to the main .Nm process and exits. -On most systems, processes created by the command that are still -running in the background when the command exits and that have -not changed their session will receive the -.Dv SIGHUP -signal when the monitor exits, since it is the terminal session leader. -To prevent this from happening, background processes started by the command -can be invoked via the -.Xr nohup 1 -command to ignore -.Dv SIGHUP . -Alternately, some systems provide a -.Xr setsid 1 -command which can be used to run the command in a new session. -In both cases, there is a potential race condition where the -command being run via +After receiving the command's exit status, the main .Nm -could exit before -.Xr nohup 1 -or -.Xr setsid 1 -have time to complete their setup. +passes the command's exit status to the security policy's close function +and exits. .Pp If no pty is used, .Nm @@ -714,13 +697,12 @@ calls sets up the execution environment as described above, and uses the .Xr execve 2 system call to run the command in the child process. -.Pp -In both cases, the main +The main .Nm -process waits until the command (or monitor) has completed, then passes the +process waits until the command has completed, then passes the command's exit status to the security policy's close function and exits. As a special case, if the policy plugin does not define a close -function and no pty is required, +function, .Nm will execute the command directly instead of calling .Xr fork 2 -- 2.40.0