The sudoers policy plugin determines a user's sudo privileges. It
is the default sudo policy plugin. The policy is driven by the
/etc/sudoers file or, optionally in LDAP. The policy format is
described in detail in the SUDOERS FILE FORMAT section. For
information on storing sudoers policy information in LDAP, please
see sudoers.ldap(5).
Configuring sudo.conf for sudoers
sudo consults the sudo.conf(5) file to determine which policy and
I/O logging plugins to load. If no sudo.conf(5) file is present,
or if it contains no Plugin lines, sudoers will be used for policy
decisions and I/O logging. To explicitly configure sudo.conf(5) to
use the sudoers plugin, the following configuration can be used.
Plugin sudoers_audit sudoers.so
Plugin sudoers_policy sudoers.so
Plugin sudoers_io sudoers.so
Starting with sudo 1.8.5, it is possible to specify optional
arguments to the sudoers plugin in the sudo.conf(5) file. Plugin
arguments, if any, should be listed after the path to the plugin
(i.e., after sudoers.so). The arguments are only effective for the
plugin that opens (and parses) the sudoers file.
For sudo version 1.9.1 and higher, this is the sudoers_audit
plugin. For older versions, it is the sudoers_policy plugin.
Multiple arguments may be specified, separated by white space. For
example:
Plugin sudoers_audit sudoers.so sudoers_mode=0400 error_recovery=false
The following plugin arguments are supported:
error_recovery=bool
The error_recovery argument can be used to control
whether sudoers should attempt to recover from syntax
errors in the sudoers file. If set to true (the
default), sudoers will try to recover from a syntax error
by discarding the portion of the line that contains the
error until the end of the line. A value of false will
disable error recovery. Prior to version 1.9.3, no error
recovery was performed.
ldap_conf=pathname
The ldap_conf argument can be used to override the
default path to the ldap.conf file.
ldap_secret=pathname
The ldap_secret argument can be used to override the
default path to the ldap.secret file.
sudoers_file=pathname
The sudoers_file argument can be used to override the
default path to the sudoers file.
sudoers_uid=uid
The sudoers_uid argument can be used to override the
default owner of the sudoers file. It should be
specified as a numeric user-ID.
sudoers_gid=gid
The sudoers_gid argument can be used to override the
default group of the sudoers file. It must be specified
as a numeric group-ID (not a group name).
sudoers_mode=mode
The sudoers_mode argument can be used to override the
default file mode for the sudoers file. It should be
specified as an octal value.
For more information on configuring sudo.conf(5), please refer to
its manual.
User Authentication
The sudoers security policy requires that most users authenticate
themselves before they can use sudo. A password is not required if
the invoking user is root, if the target user is the same as the
invoking user, or if the policy has disabled authentication for the
user or command. Unlike su(1), when sudoers requires
authentication, it validates the invoking user's credentials, not
the target user's (or root's) credentials. This can be changed via
the rootpw, targetpw and runaspw flags, described later.
If a user who is not listed in the policy tries to run a command
via sudo, mail is sent to the proper authorities. The address used
for such mail is configurable via the mailto Defaults entry
(described later) and defaults to root.
Note that no mail will be sent if an unauthorized user tries to run
sudo with the -l or -v option unless there is an authentication
error and either the mail_always or mail_badpass flags are enabled.
This allows users to determine for themselves whether or not they
are allowed to use sudo. By default, all attempts to run sudo
(successful or not) are logged, regardless of whether or not mail
is sent.
If sudo is run by root and the SUDO_USER environment variable is
set, the sudoers policy will use this value to determine who the
actual user is. This can be used by a user to log commands through
sudo even when a root shell has been invoked. It also allows the
-e option to remain useful even when invoked via a sudo-run script
or program. Note, however, that the sudoers file lookup is still
done for root, not the user specified by SUDO_USER.
sudoers uses per-user time stamp files for credential caching.
Once a user has been authenticated, a record is written containing
the user-ID that was used to authenticate, the terminal session ID,
the start time of the session leader (or parent process) and a time
stamp (using a monotonic clock if one is available). The user may
then use sudo without a password for a short period of time (5
minutes unless overridden by the timestamp_timeout option). By
default, sudoers uses a separate record for each terminal, which
means that a user's login sessions are authenticated separately.
The timestamp_type option can be used to select the type of time
stamp record sudoers will use.
Logging
By default, sudoers logs both successful and unsuccessful attempts
(as well as errors). The log_allowed and log_denied flags can be
used to control this behavior. Messages can be logged to
syslog(3), a log file, or both. The default is to log to syslog(3)
but this is configurable via the syslog and logfile settings. See
LOG FORMAT for a description of the log file format.
sudoers is also capable of running a command in a pseudo-terminal
and logging all input and/or output. The standard input, standard
output and standard error can be logged even when not associated
with a terminal. I/O logging is not on by default but can be
enabled using the log_input and log_output options as well as the
LOG_INPUT and LOG_OUTPUT command tags. See I/O LOG FILES for
details on how I/O log files are stored.
Starting with version 1.9, the log_servers setting may be used to
send event and I/O log data to a remote server running sudo_logsrvd
or another service that implements the protocol described by
sudo_logsrv.proto(5).
Command environment
Since environment variables can influence program behavior, sudoers
provides a means to restrict which variables from the user's
environment are inherited by the command to be run. There are two
distinct ways sudoers can deal with environment variables.
By default, the env_reset flag is enabled. This causes commands to
be executed with a new, minimal environment. On AIX (and Linux
systems without PAM), the environment is initialized with the
contents of the /etc/environment file. The HOME, MAIL, SHELL,
LOGNAME and USER environment variables are initialized based on the
target user and the SUDO_* variables are set based on the invoking
user. Additional variables, such as DISPLAY, PATH and TERM, are
preserved from the invoking user's environment if permitted by the
env_check or env_keep options. A few environment variables are
treated specially. If the PATH and TERM variables are not
preserved from the user's environment, they will be set to default
values. The LOGNAME and USER are handled as a single entity. If
one of them is preserved (or removed) from the user's environment,
the other will be as well. If LOGNAME and USER are to be preserved
but only one of them is present in the user's environment, the
other will be set to the same value. This avoids an inconsistent
environment where one of the variables describing the user name is
set to the invoking user and one is set to the target user.
Environment variables with a value beginning with () are removed
unless both the name and value parts are matched by env_keep or
env_check, as they may be interpreted as functions by the bash
shell. Prior to version 1.8.11, such variables were always
removed.
If, however, the env_reset flag is disabled, any variables not
explicitly denied by the env_check and env_delete options are
allowed and their values are inherited from the invoking process.
Prior to version 1.8.21, environment variables with a value
beginning with () were always removed. Beginning with version
1.8.21, a pattern in env_delete is used to match bash shell
functions instead. Since it is not possible to block all
potentially dangerous environment variables, use of the default
env_reset behavior is encouraged.
Environment variables specified by env_check, env_delete, or
env_keep may include one or more '*' characters which will match
zero or more characters. No other wildcard characters are
supported.
By default, environment variables are matched by name. However, if
the pattern includes an equal sign ('='), both the variables name
and value must match. For example, a bash shell function could be
matched as follows:
env_keep += "BASH_FUNC_my_func%%=()*"
Without the '=()*' suffix, this would not match, as bash shell
functions are not preserved by default.
The complete list of environment variables that are preserved or
removed, as modified by global Defaults parameters in sudoers, is
displayed when sudo is run by root with the -V option. Please note
that the list of environment variables to remove varies based on
the operating system sudo is running on.
Other sudoers options may influence the command environment, such
as always_set_home, secure_path, set_logname, and set_home.
On systems that support PAM where the pam_env module is enabled for
sudo, variables in the PAM environment may be merged in to the
environment. If a variable in the PAM environment is already
present in the user's environment, the value will only be
overridden if the variable was not preserved by sudoers. When
env_reset is enabled, variables preserved from the invoking user's
environment by the env_keep list take precedence over those in the
PAM environment. When env_reset is disabled, variables present the
invoking user's environment take precedence over those in the PAM
environment unless they match a pattern in the env_delete list.
Note that the dynamic linker on most operating systems will remove
variables that can control dynamic linking from the environment of
set-user-ID executables, including sudo. Depending on the
operating system this may include _RLD*, DYLD_*, LD_*, LDR_*,
LIBPATH, SHLIB_PATH, and others. These type of variables are
removed from the environment before sudo even begins execution and,
as such, it is not possible for sudo to preserve them.
As a special case, if the -i option (initial login) is specified,
sudoers will initialize the environment regardless of the value of
env_reset. The DISPLAY, PATH and TERM variables remain unchanged;
HOME, MAIL, SHELL, USER, and LOGNAME are set based on the target
user. On AIX (and Linux systems without PAM), the contents of
/etc/environment are also included. All other environment
variables are removed unless permitted by env_keep or env_check,
described above.
Finally, the restricted_env_file and env_file files are applied, if
present. The variables in restricted_env_file are applied first
and are subject to the same restrictions as the invoking user's
environment, as detailed above. The variables in env_file are
applied last and are not subject to these restrictions. In both
cases, variables present in the files will only be set to their
specified values if they would not conflict with an existing
environment variable.
