|
Doc Text:
|
Important: if this rebase instead contains *only bug fixes,* or *only enhancements*, select the correct option from the Doc Type drop-down list.
Rebase package(s) to version:
1.8.6p3
Highlights, important fixes, or notable enhancements:
- plugin API, provided by the new -devel subpackage
- sudoers is now implemented as a policy plugin
- Support for using the System Security Services Daemon (SSSD) as a source of sudoers data
- new configuration file /etc/sudo.conf for sudo frontend configuration (plugin path, coredumps, debugging, ...)
- The -D flag in sudo has been replaced with a more general debugging framework that is configured in sudo.conf
- The deprecated "noexec_file" sudoers option is no longer supported
- The "noexec" functionality has been moved out of the sudoers policy plugin and into the sudo front-end, which matches the behavior documented in the plugin writer's guide. As a result, the path to the noexec file is now specified in the sudo.conf file instead of the sudoers file
- If a user fails to authenticate and the command would be rejected by sudoers, it is now logged with command not allowed instead of N incorrect password attempts. Likewise, the mail_no_perms sudoers option now takes precedence over mail_badpass
- If the user is a member of the exempt group in sudoers, they will no longer be prompted for a password even if the -k flag is specified with the command. This makes sudo -k command consistent with the behavior one would get if the user ran sudo -k immediately before running the command.
- If the user specifes a group via sudo's -g option that matches the
target user's group in the password database, it is now allowed even if no groups are present in the Runas_Spec.
- A group ID (%#gid) may now be specified in a User_List or
Runas_List. Likewise, for non-Unix groups the syntax is %:#gid.
- visudo will now fix the mode on the sudoers file even if no changes are made unless the -f option is specified.
|