Description of problem: If the following line is used in /etc/pam.d/system-auth then gnome-screensaver-dialog will fail when attempting to unlock a screen. It repeatedly asks for the password as if the wrong password were entered. auth required pam_tally2.so deny=5 onerr=fail The following line is produced each time in syslog: Jan 17 11:22:33 ... gnome-screensaver-dialog: pam_tally2 (gnome-screensaver: auth): Error oepning /var/log/tallylog for update: Permission denied Version-Release number of selected component (if applicable): gnome-screensaver-2.16.1-5.el5.x86_64 pam-0.99.6.2-3.14.el5.x86_64 How reproducible: 100% Steps to Reproduce: 1. Modify /etc/pam.d/system-auth 2. Lock screen with gnome-screensaver-command -l 3. Attempt to unlock screen with password Actual results: Repeated password prompts and errors in syslog. Expected results: Screen unlocking on first attempt. Additional info: Directly related to https://bugzilla.redhat.com/show_bug.cgi?id=166682 Which was deferred to RHEL5 and closed. This has been a known bug for several years. Problem and potential work arounds described in http://mail.gnome.org/archives/screensaver-list/2007-July/msg00010.html NSA recommends use of pam_tally2. Their workaround for this problem is adding it to individual program pam files. See page 33. http://www.nsa.gov/notices/notic00004.cfm?Address=/snac/os/redhat/rhel5-guide-i731.pdf
Additional verification and work arounds. http://www.mail-archive.com/rhelv5-list@redhat.com/msg00022.html
The question is what can we do with that. 1) There are some easy workarounds - use onerr=succeed instead of onerr=fail 2) second workaround - prepend auth [success=1 default=ignore] pam_succeed_if.so service in xscreensaver:gnome-screensaver:kscreensaver just before the auth ... pam_tally2.so... 3) patch pam_tally2 so it ignores the open error when euid != 0 even if onerr=fail Making pam_tally2 fully work would require setuid helper which could easily reset the tally count for an user even if it wouldn't be a real login success so it would be potential security hole. So I don't think it is an option.
Actually the pam_tally2 already should return PAM_IGNORE in case the tallylog open fails due to permissions but the code wrongly tests for EPERM instead of EACCES. It should be fixed.
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-1358.html