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.
This makes it possible to use a different PAM configuration for
when "sudo -A" is used. The main use case is to only use PAM modules
that can interact with the askpass program. GitHub issue #112.
In the past, some PAM modules assumed that PAM_TTY was set and would
misbehave (or crash) if not. This was primarily obsolete versions
of Linux-PAM, so it should now be safe to remove this. Setting
PAM_TTY to an empty string can cause its own set of issues.
GitHub issue #74
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
The prompt passed in to sudo_pam_verify() will be freed later by
check_user_interactive() so we need to reset the stashed value.
From Pavel Heimlich. Bug #967.
If a PAM module wants to authenticate user using GSSAPI, the authentication
is broken if non-default ccache name is used in KRB5CCNAME environment
variable.
One way to mitigate this would be to add this to env_keep, but this also
makes the variable available in the executed command which may not
be always desirable.
This patch sets KRB5CCNAME for pam_authenticate only, if it is available
and not yet set.
This adds audit plugin support to the sudoers module, currently
only used for accept events. As a result, the sudoers file is now
initially parsed as an audit plugin.
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
HP-UX in trusted mode will display last login messages as part of
the PAM account management module by libpam_comsec. There is no
way to suppress these messages from the PAM configuration in trusted
mode so we need to filter them in the conversation function. In
regular mode, similar (but different) messages may be produced by
libpam_hpsec.
sudo_pam_approval() must not set the global pam status to an error
value if it returns AUTH_SUCCESS. Otherwise, sudo_pam_cleanup()
will call pam_end() before sudo_pam_begin_session(). This resulted
in a NULL PAM handle being used in sudo_pam_begin_session().