input/output logging. Third parties can develop and distribute their own
policy and I/O logging plugins to work seamlessly with the s\bsu\bud\bdo\bo front
end. The default security policy is _\bs_\bu_\bd_\bo_\be_\br_\bs, which is configured via the
- file _\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\be_\br_\bs, or via LDAP. See the _\bP_\bL_\bU_\bG_\bI_\bN_\bS section for more
+ file _\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\be_\br_\bs, or via LDAP. See the _\bP_\bl_\bu_\bg_\bi_\bn_\bs section for more
information.
The security policy determines what privileges, if any, a user has to run
to read the user's password and output the password to the
standard output. If the SUDO_ASKPASS environment variable is
set, it specifies the path to the helper program. Otherwise,
- if _\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\b._\bc_\bo_\bn_\bf contains a line specifying the askpass
+ if sudo.conf(4) contains a line specifying the askpass
program, that value will be used. For example:
# Path to askpass helper program
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 security policy specifies the execution
- envionment for the command. Typically, the real and effective uid and
+ environment 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).
environment as described above, and calls the execve system call in the
child process. The main s\bsu\bud\bdo\bo process waits until the command has
completed, then passes the command's exit status to the security policy's
- close method and exits. If an I/O logging plugin is configured, 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.
+ close function and exits. If an I/O logging plugin is configured or if
+ the security policy explicitly requests it, 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. As a special case, if the policy plugin
+ does not define a close function and no pty is required, s\bsu\bud\bdo\bo will
+ execute the command directly instead of calling fork(2) first.
S\bSi\big\bgn\bna\bal\bl h\bha\ban\bnd\bdl\bli\bin\bng\bg
Because the command is run as a child of the s\bsu\bud\bdo\bo process, s\bsu\bud\bdo\bo will
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.
+ all non-system processes other than itself before rebooting the system.
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,
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).
-P\bPL\bLU\bUG\bGI\bIN\bNS\bS
- Plugins are dynamically loaded based on the contents of the
- _\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\b._\bc_\bo_\bn_\bf file. If no _\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\b._\bc_\bo_\bn_\bf file is present, or it
- contains no Plugin lines, s\bsu\bud\bdo\bo will use the traditional _\bs_\bu_\bd_\bo_\be_\br_\bs security
- policy and I/O logging, which corresponds to the following _\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\b._\bc_\bo_\bn_\bf
- file.
-
- #
- # Default /etc/sudo.conf file
- #
- # Format:
- # Plugin plugin_name plugin_path plugin_options ...
- # Path askpass /path/to/askpass
- # Path noexec /path/to/sudo_noexec.so
- # Debug sudo /var/log/sudo_debug all@warn
- # Set disable_coredump true
- #
- # The plugin_path is relative to /usr/local/libexec unless
- # fully qualified.
- # The plugin_name corresponds to a global symbol in the plugin
- # that contains the plugin interface structure.
- # The plugin_options are optional.
- #
- Plugin policy_plugin sudoers.so
- Plugin io_plugin sudoers.so
+ If no I/O logging plugins are loaded and the policy plugin has not
+ defined a c\bcl\blo\bos\bse\be() function, set a command timeout or required that the
+ command be run in a new pty, s\bsu\bud\bdo\bo may execute the command directly
+ instead of running it as a child process.
- A Plugin line consists of the Plugin keyword, followed by the _\bs_\by_\bm_\bb_\bo_\bl_\b__\bn_\ba_\bm_\be
- and the _\bp_\ba_\bt_\bh to the shared object containing the plugin. The _\bs_\by_\bm_\bb_\bo_\bl_\b__\bn_\ba_\bm_\be
- is the name of the struct policy_plugin or struct io_plugin in the plugin
- shared object. The _\bp_\ba_\bt_\bh may be fully qualified or relative. If not
- fully qualified it is relative to the _\b/_\bu_\bs_\br_\b/_\bl_\bo_\bc_\ba_\bl_\b/_\bl_\bi_\bb_\be_\bx_\be_\bc directory. Any
- additional parameters after the _\bp_\ba_\bt_\bh are passed as arguments to the
- plugin's _\bo_\bp_\be_\bn function. Lines that don't begin with Plugin, Path, Debug,
- or Set are silently ignored.
-
- For more information, see the sudo_plugin(1m) manual.
-
-P\bPA\bAT\bTH\bHS\bS
- A Path line consists of the Path keyword, followed by the name of the
- path to set and its value. E.g.
-
- Path noexec /usr/local/libexec/sudo_noexec.so
- Path askpass /usr/X11R6/bin/ssh-askpass
-
- The following plugin-agnostic paths may be set in the _\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\b._\bc_\bo_\bn_\bf
- file:
-
- askpass The fully qualified path to a helper program used to read the
- user's password when no terminal is available. This may be the
- case when s\bsu\bud\bdo\bo is executed from a graphical (as opposed to
- text-based) application. The program specified by _\ba_\bs_\bk_\bp_\ba_\bs_\bs
- should display the argument passed to it as the prompt and
- write the user's password to the standard output. The value of
- _\ba_\bs_\bk_\bp_\ba_\bs_\bs may be overridden by the SUDO_ASKPASS environment
- variable.
-
- noexec The fully-qualified path to a shared library containing dummy
- versions of the e\bex\bxe\bec\bcv\bv(), e\bex\bxe\bec\bcv\bve\be() and f\bfe\bex\bxe\bec\bcv\bve\be() library
- functions that just return an error. This is used to implement
- the _\bn_\bo_\be_\bx_\be_\bc functionality on systems that support LD_PRELOAD or
- its equivalent. Defaults to _\b/_\bu_\bs_\br_\b/_\bl_\bo_\bc_\ba_\bl_\b/_\bl_\bi_\bb_\be_\bx_\be_\bc_\b/_\bs_\bu_\bd_\bo_\b__\bn_\bo_\be_\bx_\be_\bc_\b._\bs_\bo.
-
-D\bDE\bEB\bBU\bUG\bG F\bFL\bLA\bAG\bGS\bS
- s\bsu\bud\bdo\bo versions 1.8.4 and higher support a flexible debugging framework
- that can help track down what s\bsu\bud\bdo\bo is doing internally if there is a
- problem.
-
- A Debug line consists of the Debug keyword, followed by the name of the
- program to debug (s\bsu\bud\bdo\bo, v\bvi\bis\bsu\bud\bdo\bo, s\bsu\bud\bdo\bor\bre\bep\bpl\bla\bay\by), the debug file name and a
- comma-separated list of debug flags. The debug flag syntax used by s\bsu\bud\bdo\bo
- and the _\bs_\bu_\bd_\bo_\be_\br_\bs plugin is _\bs_\bu_\bb_\bs_\by_\bs_\bt_\be_\bm@_\bp_\br_\bi_\bo_\br_\bi_\bt_\by but the plugin is free to
- use a different format so long as it does not include a comma (`,').
-
- For instance:
-
- Debug sudo /var/log/sudo_debug all@warn,plugin@info
-
- would log all debugging statements at the _\bw_\ba_\br_\bn level and higher in
- addition to those at the _\bi_\bn_\bf_\bo level for the plugin subsystem.
-
- Currently, only one Debug entry per program is supported. The s\bsu\bud\bdo\bo Debug
- entry is shared by the s\bsu\bud\bdo\bo front end, s\bsu\bud\bdo\boe\bed\bdi\bit\bt and the plugins. A
- future release may add support for per-plugin Debug lines and/or support
- for multiple debugging files for a single program.
-
- The priorities used by the s\bsu\bud\bdo\bo front end, in order of decreasing
- severity, are: _\bc_\br_\bi_\bt, _\be_\br_\br, _\bw_\ba_\br_\bn, _\bn_\bo_\bt_\bi_\bc_\be, _\bd_\bi_\ba_\bg, _\bi_\bn_\bf_\bo, _\bt_\br_\ba_\bc_\be and _\bd_\be_\bb_\bu_\bg.
- Each priority, when specified, also includes all priorities higher than
- it. For example, a priority of _\bn_\bo_\bt_\bi_\bc_\be would include debug messages
- logged at _\bn_\bo_\bt_\bi_\bc_\be and higher.
-
- The following subsystems are used by the s\bsu\bud\bdo\bo front-end:
-
- _\ba_\bl_\bl matches every subsystem
-
- _\ba_\br_\bg_\bs command line argument processing
-
- _\bc_\bo_\bn_\bv user conversation
-
- _\be_\bd_\bi_\bt sudoedit
-
- _\be_\bx_\be_\bc command execution
-
- _\bm_\ba_\bi_\bn s\bsu\bud\bdo\bo main function
-
- _\bn_\be_\bt_\bi_\bf network interface handling
-
- _\bp_\bc_\bo_\bm_\bm communication with the plugin
-
- _\bp_\bl_\bu_\bg_\bi_\bn plugin configuration
-
- _\bp_\bt_\by pseudo-tty related code
-
- _\bs_\be_\bl_\bi_\bn_\bu_\bx SELinux-specific handling
-
- _\bu_\bt_\bi_\bl utility functions
-
- _\bu_\bt_\bm_\bp utmp handling
+ P\bPl\blu\bug\bgi\bin\bns\bs
+ Plugins are dynamically loaded based on the contents of the sudo.conf(4)
+ file. If no sudo.conf(4) file is present, or it contains no Plugin
+ lines, s\bsu\bud\bdo\bo will use the traditional _\bs_\bu_\bd_\bo_\be_\br_\bs security policy and I/O
+ logging. See the sudo.conf(4) manual for details of the _\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\b._\bc_\bo_\bn_\bf
+ file and the sudo_plugin(1m) manual for more information about the s\bsu\bud\bdo\bo
+ plugin architecture.
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
disables core dumps by default while it is executing (they are re-enabled
for the command that is run). To aid in debugging s\bsu\bud\bdo\bo crashes, you may
wish to re-enable core dumps by setting ``disable_coredump'' to false in
- the _\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\b._\bc_\bo_\bn_\bf file as follows:
+ the sudo.conf(4) file as follows:
Set disable_coredump false
- Note that by default, most operating systems disable core dumps from
- setuid programs, which includes s\bsu\bud\bdo\bo. To actually get a s\bsu\bud\bdo\bo core file
- you may need to enable core dumps for setuid processes. On BSD and Linux
- systems this is accomplished via the sysctl command, on Solaris the
- coreadm command can be used.
+ See the sudo.conf(4) manual for more information.
E\bEN\bNV\bVI\bIR\bRO\bON\bNM\bME\bEN\bNT\bT
s\bsu\bud\bdo\bo utilizes the following environment variables. The security policy
$ sudo sh -c "cd /home ; du -s * | sort -rn > USAGE"
S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- grep(1), su(1), stat(2), login_cap(3), passwd(4), sudoers(4),
+ su(1), stat(2), login_cap(3), passwd(4), sudo.conf(4), sudoers(4),
sudo_plugin(1m), sudoreplay(1m), visudo(1m)
H\bHI\bIS\bST\bTO\bOR\bRY\bY
file distributed with s\bsu\bud\bdo\bo or http://www.sudo.ws/sudo/license.html for
complete details.
-Sudo 1.8.6 July 10, 2012 Sudo 1.8.6
+Sudo 1.8.7 March 13, 2013 Sudo 1.8.7
projects / debian / sudo / blobdiff