Description of problem:
pam_tally2 is being utilized to deny access after 'x' attempts to sudo with an incorrect password.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. edit /etc/pam.d/system-auth and add the line "auth required pam_tally2 deny=5"
2. run 'pam_tally2 -u <user_name>' (it should be 0)
3. as another user that is allowed to sudo to <user_name> attempt to sudo and supply an incorrect password 'sudo <user_name>'
4. repeat step 3 two more time (that would make 3 attempts)
5. as the user in step 3 use sudo and supply the correct password
6. as <user_name> run 'pam_tally2 -u <user_name>'
the counter should be at 3
the counter should have reset to 0 upon successful login
According to the pam_tally2 documentation:
Account phase resets attempts counter if the user is not magic root. This
phase can be used optionally for services which don't call pam_setcred(3)
correctly or if the reset should be done regardless of the failure of the
account phase of other modules.
Looking at the source code for sudo, we find this in sudo-1.7.2p2/auth/pam.c:
* Set credentials (may include resource limits, device
* We don't check the return value here because in Linux-PAM
* it returns the last saved return code, not the return code
* for the setcred module. Because we haven't called
* this is not set and so pam_setcred() returns PAM_PERM_DENIED.
* We can't call pam_acct_mgmt() with Linux-PAM for a similar
(void) pam_setcred(pamh, PAM_ESTABLISH_CRED);
As the comment states, pam_authenticate hasn't been called and as the
man page for pam_setcred states:
It should be called to set the credentials after a user has been
authenticated and before a session is opened for the user (with
To work around this issue you have to add pam_tally2 to the account section "account required pam_tally2.so" for the counter to reset to 0.
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
after experimenting with different ways how to fix this issue in sudo I think that the "workaround" is the only possible way how to use pam_tally2 in combination with sudo.
Sudo is specific in it's usage of pam since it's authenticating the calling user and then switching to an other user. pam_setcred() is called with PAM_USER set to the target user in sudo, which makes sense. I think that the comment in the code isn't relevant to this problem. If PAM_USER is set to the calling user (the user that is being authenticated), then the counter is set to zero after a successful attempt.
Calling pam_setcred() a second time with PAM_USER set to the target user isn't probably a good idea since the API wasn't meant to be used like that and the call has side effects.
Is the "account phase" workaround acceptable for the customer?
Setting qe_test_coverage‑. There is nothing to test.