- Plug-in API has been added, provided by the new sudo-devel subpackage.
/etc/sudo.confconfiguration file for the sudo utility front-end configuration (plug-in path, coredumps, debugging and so on) has been added.
- It is possible to specify the sudoer's path, UID, GID, and file mode as options to the plug-in in the
- Support for using the System Security Services Daemon (SSSD) as a source of sudoers data has been provided.
-Dflag in the sudo utility has been replaced with a more general debugging framework that is configured in the
- The deprecated
noexec_filesudoers option is no longer supported.
noexecfunctionality has been moved out of the sudoers policy plug-in and into the sudo utility front end, which matches the behavior documented in the plug-in writer's guide. As a result, the path to the
/user/libexec/sudo_noexec.sofile is now specified in the
/etc/sudo.conffile instead of the
- If the user fails to authenticate, and the user's executed command is rejected by the rules defined in the
command now allowederror message is now logged instead of the previously used
<N> incorrect password attempts. Likewise, the
sudoersoption now takes precedence over the
- If the user is a member of the exempt group in the
sudoersfile, he will no longer be prompted for a password even if the
-koption is specified with the executed command. This makes the
sudo -kcommand consistent with the behavior one would get if running the
sudo -kcommand immediately before executing another command.
- If the user specifies a group via the sudo utility's
-goption that matches the target user's group in the password database, it is now allowed even if no groups are present in the
- A group ID (
%#gid) can now be specified in the
Runas_Listfiles. Likewise, for non-Unix groups the syntax is
- The visudo utility now fixes the mode on the sudoers file even if no changes are made, unless the
-foption is specified.
- The controlling
ttyof a suspended process was not saved by the sudo utility. Thus, the code handling the resume operation could not restore it correctly. Consequently, resume was not enabled to a suspended process run through the sudo utility. This bug has been fixed by rebasing to a new upstream version. As a result, suspending and resuming works correctly again.
- A change in the internal execution method of commands in the sudo utility was the cause of creating a new process and executing the command from there. To fix this bug, new
defaultsoption was added to restore the old behavior. Since the execution method has been implemented to correctly handle PAM session handling, I/O logging, SELinux support, and the plug-in policy close functionality, these features do not work correctly if the newly-implemented option is used. To apply this option, add the following line to the
Defaults cmnd_no_waitAs a result, if the newly-implemented option is used, commands will be executed directly by the sudo utility.
- The sudo utility set the core dump size limit to 0 to prevent the possibility of exposing the user password in the core dump file in case of an unexpected termination. However, this limit was not reset to the previous state before executing a command and the core dump size hard limit of a child process was eventually set to 0. Consequently, it was not possible to set the core dump size limit by processes run through the sudo utility. This bug was fixed by rebasing to a new upstream version; thus, setting the core dump size limit by processes run through the sudo utility works as expected.
- When initializing the global variable holding the PAM (Pluggable Authentication Modules) handle from a child process, which had a separate address space, a different PAM handle was passed to PAM API functions where the same handle was supposed to be used. Thus, the initialization had no effect on the parent's PAM handle when the
pam_end_sessions()function was called. As a consequence, dependent modules could fail to iniciate at session close in order to release resources or make important administrative changes. This bug has been fixed by rebasing to a newer upstream version, which uses the PAM API correctly (for example, initializes one PAM handle and uses it in all related PAM API function calls). As a result, PAM sessions are now closed correctly.
- Incorrect file permissions on the
/etc/sudo-ldap.conffile and missing examples in the same file led to an inconsistency with documentation provided by Red Hat. With this update, file permissions have been corrected and example configuration lines have been added. As a result,
/etc/sudo-ldap.confis now consistent with the documentation.
- When the sudo utility set up the environment in which it ran a command, it reset the value of the
RLIMIT_NPROCresource limit to the parents value of this limit if both the soft (current) and hard (maximum) values of
RLIMIT_NPROCwere not limited. An upstream patch has been provided to address this bug and
RLIMIT_NPROCcan now be set to "unlimited".
- Due to different parsing rules for comments in the
/etc/ldap.conffile, the hash ('#') character could not be used as part of a configuration value, for example in a password. It was understood as a beginning of a comment and everything following the # character was ignored. Now, the parser has been fixed to interpret the # character as a beginning of a comment only if it is at the beginning of a line. As a result, the '#' character can be used as part of a password, or any other value if needed.
- White space characters included in command arguments were not escaped before being passed to the specified command. As a consequence, incorrect arguments were passed to the specified command. This bug was fixed by rebasing to a new upstream version where the escape of command arguments is performed correctly. As a result, command arguments specified on the command line are passed to the command as expected.
sudoutility is able to consult the
/etc/nsswitch.conffile for sudoers entries and look them up in files or via LDAP (Lightweight Directory Access Protocol). Previously, when a match was found in the first database of sudoers entries, the look-up operation still continued in other databases. In Red Hat Enterprise Linux 6.4, an option has been added to the
/etc/nsswitch.conffile that allows users to specify a database after which a match of the sudoer's entry is sufficient. This eliminates the need to query any other databases; thus improving the performance of sudoer's entry look up in large environments. This behavior is not enabled by default and must be configured by adding the
[SUCCESS=return]string after a selected database. When a match is found in a database that directly precedes this string, no other databases are queried.
- This update improves sudo documentation in the section describing wildcard usage, describing what unintended consequences a wildcard character used in the command argument can have.