Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
Comment 5RHEL Program Management
2011-07-06 01:30:12 UTC
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?
Comment 12Dalibor Pospíšil
2012-11-06 11:00:18 UTC
Setting qe_test_coverage‑. There is nothing to test.
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.