From: Todd C. Miller Date: Sun, 19 Aug 2012 17:57:02 +0000 (-0400) Subject: Add COMMAND EXECUTION section that describes how sudo runs X-Git-Tag: SUDO_1_7_10~15 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=a8ea599452fb88996fb2aa94a554b541a25f79d5;p=sudo Add COMMAND EXECUTION section that describes how sudo runs the command, the extra sudo processes and signal handling. --HG-- branch : 1.7 --- diff --git a/sudo.cat b/sudo.cat index 1712ed0b9..e9d69232e 100644 --- a/sudo.cat +++ b/sudo.cat @@ -18,11 +18,8 @@ SSYYNNOOPPSSIISS DDEESSCCRRIIPPTTIIOONN ssuuddoo allows a permitted user to execute a _c_o_m_m_a_n_d as the superuser or - another user, as specified by the _s_u_d_o_e_r_s file. The real and effective - uid and gid are set to match those of the target user, as specified in - the password database, and the group vector is initialized based on the - group database (unless the --PP option was specified). See the _C_o_m_m_a_n_d - _E_n_v_i_r_o_n_m_e_n_t section below for more details. + another user, as specified by the _s_u_d_o_e_r_s file. See the _C_O_M_M_A_N_D + _E_X_E_C_U_T_I_O_N section below for more details. ssuuddoo determines who is an authorized user by consulting the file _/_e_t_c_/_s_u_d_o_e_r_s. By running ssuuddoo with the --vv option, a user can update the @@ -370,6 +367,77 @@ DDEESSCCRRIIPPTTIIOONN file will be set to their specified values as long as they would not conflict with an existing environment variable. +CCOOMMMMAANNDD EEXXEECCUUTTIIOONN + When ssuuddoo executes a command, the _s_u_d_o_e_r_s file specifies the execution + envionment for the command. Typically, the real and effective uid and + gid are set to match those of the target user, as specified in the + password database, and the group vector is initialized based on the group + database (unless the --PP option was specified). + + The _s_u_d_o_e_r_s file settings affect the following execution parameters: + + oo real and effective user ID + + oo real and effective group ID + + oo supplementary group IDs + + oo the environment list + + oo file creation mode mask (umask) + + oo SELinux role and type + + oo Solaris project + + oo Solaris privileges + + oo BSD login class + + See the _C_o_m_m_a_n_d _E_n_v_i_r_o_n_m_e_n_t section for details on how the environment + list is constructed. + + PPrroocceessss MMooddeell + If ssuuddoo has been configured with PAM support or if I/O logging is + enabled, ssuuddoo must wait until the command has completed before it will + exit. In the case of PAM, ssuuddoo must remain running so that it can close + the PAM session when the command is finished. If neither PAM nor I/O + logging are configured, ssuuddoo will execute the command without calling + fork(2). In either case, ssuuddoo sets up the execution environment as + described above, and calls the execve system call (potentially in a child + process). If I/O logging is enabled, a new pseudo-terminal (``pty'') is + created and a second ssuuddoo process is used to relay job control signals + between the user's existing pty and the new pty the command is being run + in. This extra process makes it possible to, for example, suspend and + resume the command. Without it, the command would be in what POSIX terms + an ``orphaned process group'' and it would not receive any job control + signals. + + SSiiggnnaall HHaannddlliinngg + If the command is run as a child of the ssuuddoo process (due to PAM or I/O + logging), ssuuddoo will relay signals it receives to the command. Unless the + command is being run in a new pty, the SIGHUP, SIGINT and SIGQUIT signals + are not relayed unless they are sent by a user process, not the kernel. + Otherwise, the command would receive SIGINT twice every time the user + entered control-C. Some signals, such as SIGSTOP and SIGKILL, cannot be + caught and thus will not be relayed to the command. As a general rule, + SIGTSTP should be used instead of SIGSTOP when you wish to suspend a + command being run by ssuuddoo. + + As a special case, ssuuddoo will not relay signals that were sent by the + command it is running. This prevents the command from accidentally + killing itself. On some systems, the reboot(1m) command sends SIGTERM to + all non-system processes other than itself before rebooting the systyem. + This prevents ssuuddoo from relaying the SIGTERM signal it received back to + reboot(1m), which might then exit before the system was actually rebooted, + leaving it in a half-dead state similar to single user mode. Note, + however, that this check only applies to the command run by ssuuddoo and not + any other processes that the command may create. As a result, running a + script that calls reboot(1m) or shutdown(1m) via ssuuddoo may cause the system + to end up in this undefined state unless the reboot(1m) or shutdown(1m) are + run using the eexxeecc() family of functions instead of ssyysstteemm() (which + interposes a shell between the command and the calling process). + EEXXIITT VVAALLUUEE Upon successful execution of a program, the exit status from _s_u_d_o will simply be the exit status of the program that was executed. diff --git a/sudo.man.in b/sudo.man.in index c2f10a60f..fd78ffde6 100644 --- a/sudo.man.in +++ b/sudo.man.in @@ -86,13 +86,8 @@ allows a permitted user to execute a as the superuser or another user, as specified by the \fIsudoers\fR file. -The real and effective uid and gid are set to match those of the -target user, as specified in the password database, and the group -vector is initialized based on the group database (unless the -\fB\-P\fR -option was specified). See the -\fICommand Environment\fR +\fICOMMAND EXECUTION\fR section below for more details. .PP \fBsudo\fR @@ -924,6 +919,147 @@ Finally, if the option is defined, any variables present in that file will be set to their specified values as long as they would not conflict with an existing environment variable. +.SH "COMMAND EXECUTION" +When +\fBsudo\fR +executes a command, the +\fIsudoers\fR +file specifies the execution envionment for the command. +Typically, the real and effective uid and gid are set to +match those of the target user, as specified in the password database, +and the group vector is initialized based on the group database +(unless the +\fB\-P\fR +option was specified). +.PP +The +\fIsudoers\fR +file settings affect the following execution parameters: +.TP 4n +\fBo\fR +real and effective user ID +.TP 4n +\fBo\fR +real and effective group ID +.TP 4n +\fBo\fR +supplementary group IDs +.TP 4n +\fBo\fR +the environment list +.TP 4n +\fBo\fR +file creation mode mask (umask) +.TP 4n +\fBo\fR +SELinux role and type +.TP 4n +\fBo\fR +Solaris project +.TP 4n +\fBo\fR +Solaris privileges +.TP 4n +\fBo\fR +BSD login class +.PP +See the +\fICommand Environment\fR +section for details on how the environment list is constructed. +.SS "Process Model" +If +\fBsudo\fR +has been configured with PAM support or if I/O logging is enabled, +\fBsudo\fR +must wait until the command has completed before it will exit. +In the case of PAM, +\fBsudo\fR +must remain running so that it can close the PAM session +when the command is finished. +If neither PAM nor I/O logging are configured, +\fBsudo\fR +will execute the command without calling +fork(2). +In either case, +\fBsudo\fR +sets up the execution environment as described above, and calls the +execve +system call (potentially in a child process). +If I/O logging is enabled, a new pseudo-terminal +(``pty'') +is created and a second +\fBsudo\fR +process is used to relay job control signals between the user's +existing pty and the new pty the command is being run in. +This extra process makes it possible to, for example, suspend +and resume the command. +Without it, the command would be in what POSIX terms an +``orphaned process group'' +and it would not receive any job control signals. +.SS "Signal Handling" +If the command is run as a child of the +\fBsudo\fR +process (due to PAM or I/O logging), +\fBsudo\fR +will relay signals it receives to the command. +Unless the command is being run in a new pty, the +\fRSIGHUP\fR, +\fRSIGINT\fR +and +\fRSIGQUIT\fR +signals are not relayed unless they are sent by a user process, +not the kernel. +Otherwise, the command would receive +\fRSIGINT\fR +twice every time the user entered control-C. +Some signals, such as +\fRSIGSTOP\fR +and +\fRSIGKILL\fR, +cannot be caught and thus will not be relayed to the command. +As a general rule, +\fRSIGTSTP\fR +should be used instead of +\fRSIGSTOP\fR +when you wish to suspend a command being run by +\fBsudo\fR. +.PP +As a special case, +\fBsudo\fR +will not relay signals that were sent by the command it is running. +This prevents the command from accidentally killing itself. +On some systems, the +reboot(@mansectsu@) +command sends +\fRSIGTERM\fR +to all non-system processes other than itself before rebooting +the systyem. +This prevents +\fBsudo\fR +from relaying the +\fRSIGTERM\fR +signal it received back to +reboot(@mansectsu@), +which might then exit before the system was actually rebooted, +leaving it in a half-dead state similar to single user mode. +Note, however, that this check only applies to the command run by +\fBsudo\fR +and not any other processes that the command may create. +As a result, running a script that calls +reboot(@mansectsu@) +or +shutdown(@mansectsu@) +via +\fBsudo\fR +may cause the system to end up in this undefined state unless the +reboot(@mansectsu@) +or +shutdown(@mansectsu@) +are run using the +\fBexec\fR() +family of functions instead of +\fBsystem\fR() +(which interposes a shell between the command and the calling process). .SH "EXIT VALUE" Upon successful execution of a program, the exit status from \fIsudo\fR diff --git a/sudo.mdoc.in b/sudo.mdoc.in index 1c5c3f6b6..235ac3fe0 100644 --- a/sudo.mdoc.in +++ b/sudo.mdoc.in @@ -126,13 +126,8 @@ allows a permitted user to execute a as the superuser or another user, as specified by the .Em sudoers file. -The real and effective uid and gid are set to match those of the -target user, as specified in the password database, and the group -vector is initialized based on the group database (unless the -.Fl P -option was specified). See the -.Sx Command Environment +.Sx COMMAND EXECUTION section below for more details. .Pp .Nm sudo @@ -925,6 +920,140 @@ Finally, if the option is defined, any variables present in that file will be set to their specified values as long as they would not conflict with an existing environment variable. +.Sh COMMAND EXECUTION +When +.Nm sudo +executes a command, the +.Em sudoers +file specifies the execution envionment for the command. +Typically, the real and effective uid and gid are set to +match those of the target user, as specified in the password database, +and the group vector is initialized based on the group database +(unless the +.Fl P +option was specified). +.Pp +The +.Em sudoers +file settings affect the following execution parameters: +.Bl -bullet +.It +real and effective user ID +.It +real and effective group ID +.It +supplementary group IDs +.It +the environment list +.It +file creation mode mask (umask) +.It +SELinux role and type +.It +Solaris project +.It +Solaris privileges +.It +BSD login class +.El +.Pp +See the +.Sx Command Environment +section for details on how the environment list is constructed. +.Ss Process Model +If +.Nm sudo +has been configured with PAM support or if I/O logging is enabled, +.Nm sudo +must wait until the command has completed before it will exit. +In the case of PAM, +.Nm sudo +must remain running so that it can close the PAM session +when the command is finished. +If neither PAM nor I/O logging are configured, +.Nm sudo +will execute the command without calling +.Xr fork 2 . +In either case, +.Nm sudo +sets up the execution environment as described above, and calls the +.Xr execve +system call (potentially in a child process). +If I/O logging is enabled, a new pseudo-terminal +.Pq Dq pty +is created and a second +.Nm sudo +process is used to relay job control signals between the user's +existing pty and the new pty the command is being run in. +This extra process makes it possible to, for example, suspend +and resume the command. +Without it, the command would be in what POSIX terms an +.Dq orphaned process group +and it would not receive any job control signals. +.Ss Signal Handling +If the command is run as a child of the +.Nm sudo +process (due to PAM or I/O logging), +.Nm sudo +will relay signals it receives to the command. +Unless the command is being run in a new pty, the +.Dv SIGHUP , +.Dv SIGINT +and +.Dv SIGQUIT +signals are not relayed unless they are sent by a user process, +not the kernel. +Otherwise, the command would receive +.Dv SIGINT +twice every time the user entered control-C. +Some signals, such as +.Dv SIGSTOP +and +.Dv SIGKILL , +cannot be caught and thus will not be relayed to the command. +As a general rule, +.Dv SIGTSTP +should be used instead of +.Dv SIGSTOP +when you wish to suspend a command being run by +.Nm sudo . +.Pp +As a special case, +.Nm sudo +will not relay signals that were sent by the command it is running. +This prevents the command from accidentally killing itself. +On some systems, the +.Xr reboot @mansectsu@ +command sends +.Dv SIGTERM +to all non-system processes other than itself before rebooting +the systyem. +This prevents +.Nm sudo +from relaying the +.Dv SIGTERM +signal it received back to +.Xr reboot @mansectsu@ , +which might then exit before the system was actually rebooted, +leaving it in a half-dead state similar to single user mode. +Note, however, that this check only applies to the command run by +.Nm sudo +and not any other processes that the command may create. +As a result, running a script that calls +.Xr reboot @mansectsu@ +or +.Xr shutdown @mansectsu@ +via +.Nm sudo +may cause the system to end up in this undefined state unless the +.Xr reboot @mansectsu@ +or +.Xr shutdown @mansectsu@ +are run using the +.Fn exec +family of functions instead of +.Fn system +(which interposes a shell between the command and the calling process). .Sh EXIT VALUE Upon successful execution of a program, the exit status from .Em sudo diff --git a/sudoers.cat b/sudoers.cat index 16565510e..f7619e12f 100644 --- a/sudoers.cat +++ b/sudoers.cat @@ -237,14 +237,12 @@ DDEESSCCRRIIPPTTIIOONN Cmnd_Spec_List ::= Cmnd_Spec | Cmnd_Spec ',' Cmnd_Spec_List - Cmnd_Spec ::= Runas_Spec? SELinux_Spec? Solaris_Priv_Spec? Tag_Spec* Cmnd + Cmnd_Spec ::= Runas_Spec? SELinux_Spec? Tag_Spec* Cmnd Runas_Spec ::= '(' Runas_List? (':' Runas_List)? ')' SELinux_Spec ::= ('ROLE=role' | 'TYPE=type') - Solaris_Priv_Spec ::= ('PRIVS=privset' | 'LIMITPRIVS=privset') - Tag_Spec ::= ('NOPASSWD:' | 'PASSWD:' | 'NOEXEC:' | 'EXEC:' | 'SETENV:' | 'NOSETENV:' | 'LOG_INPUT:' | 'NOLOG_INPUT:' | 'LOG_OUTPUT:' | 'NOLOG_OUTPUT:') @@ -332,32 +330,6 @@ DDEESSCCRRIIPPTTIIOONN in _s_u_d_o_e_r_s. A role or type specified on the command line, however, will supersede the values in _s_u_d_o_e_r_s. - SSoollaarriiss__PPrriivv__SSppeecc - On Solaris systems, _s_u_d_o_e_r_s entries may optionally specify Solaris - privilege set and/or limit privilege set associated with a command. If - privileges or limit privileges are specified with the command it will - override any default values specified in _s_u_d_o_e_r_s. - - A privilege set is a comma-separated list of privilege names. The - ppriv(1) command can be used to list all privileges known to the system. - For example: - - $ ppriv -l - - In addition, there are several ``special'' privilege strings: - - none the empty set - - all the set of all privileges - - zone the set of all privileges available in the current zone - - basic the default set of privileges normal users are granted at login - time - - Privileges can be excluded from a set by prefixing the privilege name - with either an `!' or `-' character. - TTaagg__SSppeecc A command may have zero or more tags associated with it. There are ten possible tag values: NOPASSWD, PASSWD, NOEXEC, EXEC, SETENV, NOSETENV, @@ -1051,16 +1023,6 @@ SSUUDDOOEERRSS OOPPTTIIOONNSS The default value is ``Password:''. - privs The default Solaris privileges to use when constructing - a new privilege set for a command. This is passed to - the executing process via the inherited privilege set, - but is bounded by the limit privileges. If the _p_r_i_v_s - option is specified but the _l_i_m_i_t_p_r_i_v_s option is not, - the limit privileges of the executing process is set to - _p_r_i_v_s. The default privileges may be overridden on a - per-command basis in _s_u_d_o_e_r_s. This option is only - available if ssuuddooeerrss is built on Solaris 10 or higher. - role The default SELinux role to use when constructing a new security context to run the command. The default role may be overridden on a per-command basis in _s_u_d_o_e_r_s or diff --git a/sudoers.man.in b/sudoers.man.in index 22ad5a043..e1967060d 100644 --- a/sudoers.man.in +++ b/sudoers.man.in @@ -457,14 +457,12 @@ User_Spec ::= User_List Host_List '=' Cmnd_Spec_List \e Cmnd_Spec_List ::= Cmnd_Spec | Cmnd_Spec ',' Cmnd_Spec_List -Cmnd_Spec ::= Runas_Spec? SELinux_Spec? Solaris_Priv_Spec? Tag_Spec* Cmnd +Cmnd_Spec ::= Runas_Spec? SELinux_Spec? Tag_Spec* Cmnd Runas_Spec ::= '(' Runas_List? (':' Runas_List)? ')' SELinux_Spec ::= ('ROLE=role' | 'TYPE=type') -Solaris_Priv_Spec ::= ('PRIVS=privset' | 'LIMITPRIVS=privset') - Tag_Spec ::= ('NOPASSWD:' | 'PASSWD:' | 'NOEXEC:' | 'EXEC:' | 'SETENV:' | 'NOSETENV:' | 'LOG_INPUT:' | 'NOLOG_INPUT:' | 'LOG_OUTPUT:' | 'NOLOG_OUTPUT:') @@ -668,49 +666,6 @@ specified in A role or type specified on the command line, however, will supersede the values in \fIsudoers\fR. -.SS "Solaris_Priv_Spec" -On Solaris systems, -\fIsudoers\fR -entries may optionally specify Solaris privilege set and/or limit -privilege set associated with a command. -If privileges or limit privileges are specified with the command -it will override any default values specified in -\fIsudoers\fR. -.PP -A privilege set is a comma-separated list of privilege names. -The -ppriv(1) -command can be used to list all privileges known to the system. -For example: -.nf -.sp -.RS 0n -$ ppriv -l -.RE -.fi -.PP -In addition, there are several -``special'' -privilege strings: -.TP 10n -none -the empty set -.TP 10n -all -the set of all privileges -.TP 10n -zone -the set of all privileges available in the current zone -.TP 10n -basic -the default set of privileges normal users are granted at login time -.PP -Privileges can be excluded from a set by prefixing the privilege -name with either an -`\&!' -or -`\-' -character. .SS "Tag_Spec" A command may have zero or more tags associated with it. There are @@ -2208,24 +2163,6 @@ The default value is .RE .PD 0 .TP 18n -privs -The default Solaris privileges to use when constructing a new -privilege set for a command. -This is passed to the executing process via the inherited privilege set, -but is bounded by the limit privileges. -If the -\fIprivs\fR -option is specified but the -\fIlimitprivs\fR -option is not, the limit privileges of the executing process is set to -\fIprivs\fR. -The default privileges may be overridden on a per-command basis in -\fIsudoers\fR. -This option is only available if -\fBsudoers\fR -is built on Solaris 10 or higher. -.PD -.TP 18n role The default SELinux role to use when constructing a new security context to run the command. @@ -2235,6 +2172,7 @@ or via command line options. This option is only available when \fBsudo\fR is built with SELinux support. +.PD .TP 18n runas_default The default user to run commands as if the