Red Hat Bugzilla – Bug 133854
Allow using pam_tally.so without root privileges when RUSER==USER
Last modified: 2015-01-07 19:08:36 EST
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.
When trying to log in from xscreensaver, I get
Sep 27 14:19:01 dragon pam_tally: 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: Error opening /var/log/faillog
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?
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).
What's your thoughts on this Tomas?
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 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.
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.
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.
*** Bug 166682 has been marked as a duplicate of this bug. ***