the command, the extra sudo processes and signal handling.
--HG--
branch : 1.7
D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
s\bsu\bud\bdo\bo allows a permitted user to execute a _\bc_\bo_\bm_\bm_\ba_\bn_\bd as the superuser or
- another user, as specified by the _\bs_\bu_\bd_\bo_\be_\br_\bs 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 -\b-P\bP option was specified). See the _\bC_\bo_\bm_\bm_\ba_\bn_\bd
- _\bE_\bn_\bv_\bi_\br_\bo_\bn_\bm_\be_\bn_\bt section below for more details.
+ another user, as specified by the _\bs_\bu_\bd_\bo_\be_\br_\bs file. See the _\bC_\bO_\bM_\bM_\bA_\bN_\bD
+ _\bE_\bX_\bE_\bC_\bU_\bT_\bI_\bO_\bN section below for more details.
s\bsu\bud\bdo\bo determines who is an authorized user by consulting the file
_\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\be_\br_\bs. By running s\bsu\bud\bdo\bo with the -\b-v\bv option, a user can update the
file will be set to their specified values as long as they would not
conflict with an existing environment variable.
+C\bCO\bOM\bMM\bMA\bAN\bND\bD E\bEX\bXE\bEC\bCU\bUT\bTI\bIO\bON\bN
+ When s\bsu\bud\bdo\bo executes a command, the _\bs_\bu_\bd_\bo_\be_\br_\bs 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 -\b-P\bP option was specified).
+
+ The _\bs_\bu_\bd_\bo_\be_\br_\bs file settings affect the following execution parameters:
+
+ o\bo real and effective user ID
+
+ o\bo real and effective group ID
+
+ o\bo supplementary group IDs
+
+ o\bo the environment list
+
+ o\bo file creation mode mask (umask)
+
+ o\bo SELinux role and type
+
+ o\bo Solaris project
+
+ o\bo Solaris privileges
+
+ o\bo BSD login class
+
+ See the _\bC_\bo_\bm_\bm_\ba_\bn_\bd _\bE_\bn_\bv_\bi_\br_\bo_\bn_\bm_\be_\bn_\bt section for details on how the environment
+ list is constructed.
+
+ P\bPr\bro\boc\bce\bes\bss\bs M\bMo\bod\bde\bel\bl
+ If s\bsu\bud\bdo\bo has been configured with PAM support or if I/O logging is
+ enabled, s\bsu\bud\bdo\bo must wait until the command has completed before it will
+ exit. In the case of PAM, s\bsu\bud\bdo\bo 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, s\bsu\bud\bdo\bo will execute the command without calling
+ fork(2). In either case, s\bsu\bud\bdo\bo 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 s\bsu\bud\bdo\bo 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.
+
+ S\bSi\big\bgn\bna\bal\bl H\bHa\ban\bnd\bdl\bli\bin\bng\bg
+ If the command is run as a child of the s\bsu\bud\bdo\bo process (due to PAM or I/O
+ logging), s\bsu\bud\bdo\bo 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 s\bsu\bud\bdo\bo.
+
+ As a special case, s\bsu\bud\bdo\bo 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 s\bsu\bud\bdo\bo 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 s\bsu\bud\bdo\bo and not
+ any other processes that the command may create. As a result, running a
+ script that calls reboot(1m) or shutdown(1m) via s\bsu\bud\bdo\bo may cause the system
+ to end up in this undefined state unless the reboot(1m) or shutdown(1m) are
+ run using the e\bex\bxe\bec\bc() family of functions instead of s\bsy\bys\bst\bte\bem\bm() (which
+ interposes a shell between the command and the calling process).
+
E\bEX\bXI\bIT\bT V\bVA\bAL\bLU\bUE\bE
Upon successful execution of a program, the exit status from _\bs_\bu_\bd_\bo will
simply be the exit status of the program that was executed.
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
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
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
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
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:')
in _\bs_\bu_\bd_\bo_\be_\br_\bs. A role or type specified on the command line, however, will
supersede the values in _\bs_\bu_\bd_\bo_\be_\br_\bs.
- S\bSo\bol\bla\bar\bri\bis\bs_\b_P\bPr\bri\biv\bv_\b_S\bSp\bpe\bec\bc
- On Solaris systems, _\bs_\bu_\bd_\bo_\be_\br_\bs 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 _\bs_\bu_\bd_\bo_\be_\br_\bs.
-
- 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.
-
T\bTa\bag\bg_\b_S\bSp\bpe\bec\bc
A command may have zero or more tags associated with it. There are ten
possible tag values: NOPASSWD, PASSWD, NOEXEC, EXEC, SETENV, NOSETENV,
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 _\bp_\br_\bi_\bv_\bs
- option is specified but the _\bl_\bi_\bm_\bi_\bt_\bp_\br_\bi_\bv_\bs option is not,
- the limit privileges of the executing process is set to
- _\bp_\br_\bi_\bv_\bs. The default privileges may be overridden on a
- per-command basis in _\bs_\bu_\bd_\bo_\be_\br_\bs. This option is only
- available if s\bsu\bud\bdo\boe\ber\brs\bs 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 _\bs_\bu_\bd_\bo_\be_\br_\bs or
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:')
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
.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.
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
projects / sudo / commitdiff