Hide Forgot
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): 1.7.2-p2 How reproducible: Very 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>' Actual results: the counter should be at 3 Expected results: the counter should have reset to 0 upon successful login Additional info: According to the pam_tally2 documentation: <snip> ACCOUNT OPTIONS 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. </snip> Looking at the source code for sudo, we find this in sudo-1.7.2p2/auth/pam.c: <snip> /* * Set credentials (may include resource limits, device ownership, etc). * We don't check the return value here because in Linux-PAM 0.75 * it returns the last saved return code, not the return code * for the setcred module. Because we haven't called pam_authenticate(), * 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 reason. */ (void) pam_setcred(pamh, PAM_ESTABLISH_CRED); </snip> As the comment states, pam_authenticate hasn't been called and as the man page for pam_setcred states: <snip> It should be called to set the credentials after a user has been authenticated and before a session is opened for the user (with pam_open_session(3)). </snip> 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 representative.
Hello, 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.