Bug 133854 (IT_49312)

Summary:	Allow using pam_tally.so without root privileges when RUSER==USER
Product:	Red Hat Enterprise Linux 2.1	Reporter:	Martin Hunt <hunt>
Component:	pam	Assignee:	Tomas Mraz <tmraz>
Status:	CLOSED DEFERRED	QA Contact:	Jay Turner <jturner>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	2.1	CC:	laroche, rstrode, smooge, srevivo, tao, tmraz
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-03-21 13:36:06 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 Martin Hunt 2004-09-27 21:42:48 UTC

If pam_tally is configured to disable logins after a certain number of
failures, then xscreensaver's lock screen functions will not work
properly with it.  It will disable logins for a user through
xscreensaver, but not through virtual terminals.

Comment 1 Martin Hunt 2004-09-27 21:44:37 UTC

http://www.redhat.com/archives/fedora-list/2004-April/msg02907.html

Comment 2 Martin Hunt 2004-09-27 21:47:48 UTC

When trying to log in from xscreensaver, I get
Sep 27 14:19:01 dragon pam_tally[3001]: Couldn't create /var/log/faillog

later, after a login failure from the console creates
/var/log/faillog, I get

Sep 27 14:20:52 dragon pam_tally[3001]: Error opening /var/log/faillog
for update

Comment 3 David Lehman 2004-10-25 17:56:54 UTC

This is because faillog (and pam_tally.so for that matter) incorrectly
assume they will be run as root. Any thoughts whether it's user app or
pam that's broken?

Comment 4 Ray Strode [halfline] 2004-10-25 20:54:17 UTC

Note I haven't really investigated this bug yet, but off the top of my
head I have a few unsubstantiated comments:

1) pam session modules require the app to have sufficient (root)
privileges.  It says so in one of the pam man pages.  This is a bit of
a side point because pam_tally isn't a session module.

2) Does that mean that apps should have root privileges before using
auth and account modules (like pam_tally), too?  I don't know.  I
guess it boils down to, "Should a program need root privileges to ask
if a user can login?"   I believe other pam modules (pam_unix and
pam_pwdb) answer that question by saying "a program can verify that
its own user can login without root privileges, but not other users",
and I think they implement this answer by using a setuid helper binary
(/sbin/unix_chkpwd and /sbin/pwdb_chkpwd respectively).

Comment 5 Ray Strode [halfline] 2004-10-26 14:55:32 UTC

What's your thoughts on this Tomas?

Comment 6 Tomas Mraz 2004-10-26 15:11:28 UTC

I completely agree with you. We would have to provide an suid binary
which would do the faillog management and the pam_tally module would
only call this binary. This would be a really substantial change of
the module.

The problem is the pam_tally module has other serious bugs (as bug
60930) and so it would be good idea to rewrite it. But I think it
isn't something which could be done for RHEL 2.1 or 3 or even 4.

Comment 7 Ray Strode [halfline] 2004-10-26 15:41:43 UTC

Okay I'm going to assign this to you then, so you can triage it
however you triage "would be nice for RHEL5" type bugs.

Comment 9 Tomas Mraz 2005-03-21 13:36:06 UTC

I don't think this will be implemented in the next RHEL release. The more I
think about this problem the more it seems to me that the xscreensaver should
run setuid binary to verify the username/password instead of calling PAM itself.

Comment 10 Stephen John Smoogen 2005-08-24 19:25:51 UTC

*** Bug 166682 has been marked as a duplicate of this bug. ***