---

   sudoers    ( 5 )

---

Имя (Name)

sudoers — default sudo security policy plugin

Описание (Description)

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.