We rely on the include path to find many of these headers. It
especially doesn't make sense to use #include "foo.h" for headers
in the top-level include directory.
The getpass callbacks are now defined in sudo_auth.c, which implements
auth_getpass(). As a result, struct getpass_closure is now public
and defined in timestamp.h.
We now pass a pointer to the context where necessary. There are a
few cases where we need to request the context from sudoers via
sudoers_get_context() for the plugin API functions. If the plugin
API was able to pass around a closure pointer this would not be
necessary.
Previously we were calling the PAM approval modules even in intercept
mode which can take a lot of time. We may wish to make PAM approval
configurable in intercept mode in the future.
sudoers now supports an APPARMOR_PROFILE option, which can be specified
as e.g.
alice ALL=(ALL:ALL) APPARMOR_PROFILE=foo ALL
The line above says "user alice can run any command as any user/group,
under confinement by the AppArmor profile 'foo'." Profiles can be
specified in any way that complies with the rules of
aa_change_profile(2). For instance, the sudoers configuration
alice ALL=(ALL:ALL) APPARMOR_PROFILE=unconfined ALL
allows alice to run any command unconfined (i.e., without an AppArmor
profile), while
alice ALL=(ALL:ALL) APPARMOR_PROFILE=foo//&bar ALL
tells sudoers that alice can run any command under the stacked AppArmor
profiles 'foo' and 'bar'.
The intention of this option is to give sysadmins on Linux distros
supporting AppArmor better options for fine-grained access control.
Among other things, this option can enforce mandatory access control
(MAC) over the operations that a privileged user is able to perform to
ensure that they cannot privesc past the boundaries of a specified
profile. It can also be used to limit which users are able to get
unconfined system access, by enforcing a default AppArmor profile on all
users and then specifying 'APPARMOR_PROFILE=unconfined' for a privileged
subset of users.
This means we no longer display the lecture unless the user is going
to enter a password. Authentication methods that don't interact
with the user via the terminal don't trigger the lecture.
If noninteractive_auth is set, authentication methods that do not
require input from the user's terminal may proceed. It is off by
default, which restores the pre-1.9.9 behavior of "sudo -n".
For "sudo -n" we only want to reject a command if user input is
actually required. In the case of PAM at least, we may not need
to interact with the user. Bug #956, GitHub issue #83
By default, sudoers will not require authentication of commands run
via an intercepted session. To require authenticaton of subsequent
commands, enable intercept_authenticate in sudoers.
Previously we needed to include headers required by the various
sudo*h files. Now those files are more self-sufficient and we
should only include headers needed by code in the various .c files.
This is used for PAM authentication to make sure pam_end() is called
via sudo_auth_cleanup() when the user authenticates successfully but
sudoers denies the command. Debian bug #669687
The closure pointer in sudo_conv_callback was being filled in with
a struct getpass_closure ** instead of a struct getpass_closure *.
The bug was introduced in the fix for Bug #910; previously the
closure variable was a struct getpass_closure, not a pointer.
Fix from Michael Norton; Bug #914.
the user's password has been verified. The approval function is
run even if no password is required. This is currently only used
for PAM (use pam_acct_mgmt) and BSD auth (auth_approval).
If suspended, close the timestamp file (dropping all locks). On
resume, lock the record before reading the password.
For this to work properly we need to be able to run th callback
when tsetattr() suspends us, not just when the user does. To
accomplish this the term_* functions now return EINTR if SIGTTOU
would be generated. The caller now has to restart the term_*
function (and send itself SIGTTOU) instead of it being done
automatically.
