Description of problem: When one has defined "lock_time=1" into the PAM config file used for authentication, fast simultaneous authentication from two different processes fail randomly even though username and password are correct. How reproducible: Put two authenticators running simultaneously in a tight loop each using the same PAM config file. Use correct username and password. Steps to Reproduce: 1) compile the reproducer pam_authenticate.c (-lpam -lpam_misc) 2) copy files pam-test-1 & pam-test-2 to /etc/pam.d. 3) create a test user. 4) run two instances in two different terminals of: ./pam_authenticate pam-test-1 test_user password Actual results: This message appears from time to time: pam_tally2: user test_user (500) has time limit [1s left] since last failure. This happens when: a) One process is run in a tight loop. b) Two processes authenticating in a tight look are run with pam_tally lock_time=1 parameter. This can be testing using the pam-test-2 config file. Expected results: No messages or errors should be shown. Additional comments: Attachments: test case pam_authenticate.c and both pam-test-1,pam-test-2 for testing.
Created attachment 305095 [details] pam_authenticate.c
Created attachment 305097 [details] ... auth required pam_tally2.so lock_time=1 unlock_time=3600 deny=5 ...
Created attachment 305099 [details] [pam-test-2] ... auth required pam_tally2.so unlock_time=3600 deny=5 ... Above is pam-test-1
I'm sorry but this is inherent problem in the way how pam_tally/pam_tally2 works. We would have to serialize all authentication attempts through PAM so before one attempt is not finished yet the other attempt will be waiting for a lock to be released. I do not think it is a bug strictly speaking, because the result of the attempt of the authentication which is in progress is not yet determined so if you are using the lock_time=1 option it means the tally lock is in effect during it. Of course even without the lock_time=1 with sufficiently low deny value it could eventually happen because if there are more than deny attempts simultaneously happening the tally lock will be in effect for the following attempts. I could add an option to pam_tally which would serialize the authentication attempts but I'd prefer to not to turn it on by default.
We need a NSN committment to test the patch as soon as it is available.
Yes. NSN commit to test this. This event sent from IssueTracker by sprabhu issue 167119
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0995.html