Bug 133854 - (IT_49312) Allow using pam_tally.so without root privileges when RUSER==USER
Allow using pam_tally.so without root privileges when RUSER==USER
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: pam (Show other bugs)
2.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Jay Turner
: FutureFeature
: 166682 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-27 17:42 EDT by Martin Hunt
Modified: 2015-01-07 19:08 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-21 08:36:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Hunt 2004-09-27 17:42:48 EDT
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 2 Martin Hunt 2004-09-27 17:47:48 EDT
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 13:56:54 EDT
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 16:54:17 EDT
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 10:55:32 EDT
What's your thoughts on this Tomas?
Comment 6 Tomas Mraz 2004-10-26 11:11:28 EDT
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 11:41:43 EDT
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 08:36:06 EST
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 15:25:51 EDT
*** Bug 166682 has been marked as a duplicate of this bug. ***

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