mirror of
https://github.com/sudo-project/sudo.git
synced 2025-08-22 01:49:11 +00:00
Background processes started by the command will no longer receive
SIGHUP.
This commit is contained in:
Todd C. Miller
parent
b561d0d7dd
commit
c2eee7904d
34
doc/sudo.cat
34
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
|
||||
|
||||
@ -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
|
||||
After receiving the command's exit status, the main
|
||||
\fBsudo\fR
|
||||
could exit before
|
||||
nohup(1)
|
||||
or
|
||||
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,
|
||||
\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)
|
||||
|
||||
@ -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
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user