Bug 429169 - pam_tally2 in system-auth prevents gnome-screensaver from unlocking
pam_tally2 in system-auth prevents gnome-screensaver from unlocking
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pam (Show other bugs)
All Linux
low Severity high
: rc
: ---
Assigned To: Tomas Mraz
Depends On:
  Show dependency treegraph
Reported: 2008-01-17 13:31 EST by Bryan Schneiders
Modified: 2009-09-02 07:24 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 07:24:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bryan Schneiders 2008-01-17 13:31:31 EST
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):

How reproducible:

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

Problem and potential work arounds described in

NSA recommends use of pam_tally2.  Their workaround for this problem is adding
it to individual program pam files.  See page 33. 
Comment 1 Bryan Schneiders 2008-01-17 13:55:38 EST
Additional verification and work arounds.

Comment 2 Tomas Mraz 2008-01-18 04:31:13 EST
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

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.

Comment 3 Tomas Mraz 2008-12-12 09:19:55 EST
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.
Comment 8 errata-xmlrpc 2009-09-02 07:24:31 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.