Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 429169

Summary:	pam_tally2 in system-auth prevents gnome-screensaver from unlocking
Product:	Red Hat Enterprise Linux 5	Reporter:	Bryan Schneiders <bschneiders>
Component:	pam	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED ERRATA	QA Contact:
Severity:	high	Docs Contact:
Priority:	low
Version:	5.0	CC:	bschneiders, ohudlick, sgrubb
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-09-02 11:24:31 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Bryan Schneiders 2008-01-17 18:31:31 UTC

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

Comment 1 Bryan Schneiders 2008-01-17 18:55:38 UTC

Additional verification and work arounds.

http://www.mail-archive.com/rhelv5-list@redhat.com/msg00022.html

Comment 2 Tomas Mraz 2008-01-18 09:31:13 UTC

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.

Comment 3 Tomas Mraz 2008-12-12 14:19:55 UTC

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 11:24:31 UTC

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