Bug 36670 - Pam authentication failure
Summary: Pam authentication failure
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pam
Version: 7.1
Hardware: i386
OS: Linux
high
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Keywords:
: 39174 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-04-19 16:31 UTC by Need Real Name
Modified: 2007-03-27 03:43 UTC (History)
4 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2002-03-20 20:03:12 UTC


Attachments (Terms of Use)

Description Need Real Name 2001-04-19 16:31:58 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.4-pre4 i686; Nav)


When xscreensaver is running (ie the screen is locked) it happens that I
cannot logon again : I have to kill my X server... Because if I kill
xscreensaver, I can't input anything in X!

Reproducible: Sometimes
Steps to Reproduce:
1. run xscreensaver&
2. run xscreensaver-command -lock
3. try to logon. that's it
	

Actual Results:  I got those in the syslog
Apr 19 11:43:01 shookay xscreensaver(pam_unix)[2957]: authentication
failure; logname= uid=500 euid=500 tty=:0.0 ruser= rhost=  user=mchouque
Apr 19 11:43:03 shookay xscreensaver(pam_unix)[2957]: authentication
failure; logname= uid=500 euid=500 tty=:0.0 ruser= rhost=  user=root


Expected Results:  I should have been able to log on again!

On one of my other machine (freshly installed), I got a message on the
xscreensaver screen (those yellow debug outputs) saying that on of my
program failed... I could not copy and paste the message but I will try to
get it if it happens again.

Comment 1 Bill Nottingham 2001-04-19 16:34:47 UTC
What does /etc/pam.d/xscreensaver and /etc/pam.d/system-auth say?

Comment 2 Need Real Name 2001-04-19 17:26:39 UTC
/etc/pam.d/xscreensaver:
#%PAM-1.0
auth       required     /lib/security/pam_stack.so service=system-auth

/etc/pam.d/system-auth:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/pam_env.so
auth        sufficient    /lib/security/pam_unix.so likeauth nullok
auth        required      /lib/security/pam_deny.so

account     required      /lib/security/pam_unix.so

password    required      /lib/security/pam_cracklib.so retry=3
password    sufficient    /lib/security/pam_unix.so nullok use_authtok md5
shadow
password    required      /lib/security/pam_deny.so

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so


Comment 3 Bill Nottingham 2001-04-19 17:47:00 UTC
Is your password in /etc/shadow?  I'm assuming you're *sure* you're typing
it in right.

Comment 4 Need Real Name 2001-04-19 17:50:08 UTC
Yep my password is in /etc/shadow and for the typing, I am 100% sure (I tried
multiple times to be sure and that occurs to my computer at home too).

Comment 5 Bill Nottingham 2001-04-19 17:58:01 UTC
Fresh install or upgrade?

Comment 6 Bill Nottingham 2001-04-19 17:58:28 UTC
(and what exact version of pam?)

Comment 7 Bill Nottingham 2001-04-19 18:02:49 UTC
Also, do you have anything in /var/log/secure?

Comment 8 Bill Nottingham 2001-04-19 18:04:08 UTC
Also, (while I'm throwing out ideas), can you add 'debug' to the arguments
for pam_unix.so in /etc/pam.d/system-auth, and see if you get more verbose
failure messages?



Comment 9 Need Real Name 2001-04-19 18:15:03 UTC
Ok I tried that. Strangely the first attempt worked perfectly but not the second
and the subsequent ones...
I got these in secure (2nd attempts and subsequents):
Apr 19 14:11:53 shookay xscreensaver[5728]: FAILED LOGIN 1 ON DISPLAY ":0.0",
FOR "mchouque"
Apr 19 14:12:02 shookay xscreensaver[5728]: FAILED LOGIN 2 ON DISPLAY ":0.0",
FOR "mchouque"
Apr 19 14:12:13 shookay xscreensaver[5728]: FAILED LOGIN 3 ON DISPLAY ":0.0",
FOR "mchouque"

and those in messages:
Apr 19 14:11:48 shookay xscreensaver(pam_unix)[5728]: authentication failure;
logname=mchouque uid=500 euid=500 tty=:0.0 ruser= rhost=  user=mchouque
Apr 19 14:11:50 shookay xscreensaver(pam_unix)[5728]: authentication failure;
logname=mchouque uid=500 euid=500 tty=:0.0 ruser= rhost=  user=root
Apr 19 14:11:58 shookay xscreensaver(pam_unix)[5728]: authentication failure;
logname=mchouque uid=500 euid=500 tty=:0.0 ruser= rhost=  user=mchouque
Apr 19 14:11:59 shookay xscreensaver(pam_unix)[5728]: authentication failure;
logname=mchouque uid=500 euid=500 tty=:0.0 ruser= rhost=  user=root
Apr 19 14:12:09 shookay xscreensaver(pam_unix)[5728]: authentication failure;
logname=mchouque uid=500 euid=500 tty=:0.0 ruser= rhost=  user=mchouque
Apr 19 14:12:11 shookay xscreensaver(pam_unix)[5728]: authentication failure;
logname=mchouque uid=500 euid=500 tty=:0.0 ruser= rhost=  user=root


Comment 10 Bill Nottingham 2001-04-22 20:38:29 UTC
Are you running the shipped kernel, or something else?

If you're not running 2.4.2-2, please try that.

Comment 11 Need Real Name 2001-04-23 14:02:45 UTC
I am running 2.4.4-pre4... I'll try redhat kernel!

Comment 12 Need Real Name 2001-04-23 16:46:06 UTC
Ok, I didn't try redhat kernel but tried 2.4.4-pre6 instead. No luck. It seems
that only the first try works. Now, I will try the redhat kernel...

Comment 13 Need Real Name 2001-04-23 17:53:13 UTC
Ok, this time, that's it: this is a kernel dependent problem because
xscreensaver works perfectly well with the redhat kernel (2.4.2-2 with my own
settings).


Comment 14 Bill Nottingham 2001-04-24 03:24:23 UTC
Actually, it appears to be a pam bug; it only works sort of by accident.

Comment 15 Nils Philippsen 2001-04-26 18:13:50 UTC
Ok, it's the same with me here. I tried various combinations of different
pam and xscreensaver versions but to no avail. What makes me very suspicious is
that if I (temporarily of course) grant read access to normal users on
/etc/shadow, I can unlock X. There seems to be something weird happening in
/sbin/unix_chkpwd and /sbin/pwdb_chkpwd (I used the latter after the first
showed the error).

I recompiled my pwdb with -DDEBUG and saw that it can't get hold of the real
password entry if the file is only readable by root (it just gets the 'x' from
/etc/passwd). This doesn't happen if /etc/shadow is readable by everyone. Very
strange indeed -- both helper programs are setuid root.

Comment 16 Bill Nottingham 2001-04-26 19:12:24 UTC
It's actually a race condition (sort of). unix_chkpwd is getting
reaped by xscreensaver instead of by PAM.


Comment 17 Bill Nottingham 2001-05-07 13:46:12 UTC
*** Bug 39174 has been marked as a duplicate of this bug. ***

Comment 18 Valdis Kletnieks 2001-05-09 23:17:37 UTC
Problem seen with xscreensaver 3.29-1 and 3.32-1 on a 2.4.4 kernel, I don't
remember seeing it with 3.29 on a 2.4.3 kernel - haven't rebooted back to 2.4.3
to double-check however.

Comment 19 Need Real Name 2001-05-09 23:21:37 UTC
It could be to child first fork change!
Linus undid that in the latest 2.4.5-presomething because many applications were
freaking out with that thing...
I'll give a shot tomorrow!

Comment 20 Bill Nottingham 2001-05-10 00:32:31 UTC
That is exactly what the problem is... that change exposes a pam problem.

Comment 21 jmbastia 2002-03-20 20:03:07 UTC
The same problem exists with xlock on both RedHat 7.1 and 7.2 as well.  I
upgraded pam a few days ago on 40 machines running RH 7.1, and it wasn't long
before people noticed that they couldn't unlock an xlocked machine.  I have a
test machine running RH 7.2, and the same problem exists there.

Packages on RH 7.1 machines:
  pam-0.75-18.7
  xlockmore-4.17.2-1

Packages on RH 7.2 machines:
  pam-0.75-19
  xlockmore-4.17.2-4


Comment 22 Need Real Name 2004-07-08 09:53:08 UTC
The race condition is also triggered if you use kernel preemption.


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