Bug 36670
| Summary: | Pam authentication failure | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <mchouque> |
| Component: | pam | Assignee: | Nalin Dahyabhai <nalin> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.1 | CC: | jmbastia, notting, nphilipp, rh-bugzilla |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2002-03-20 20:03:12 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
Need Real Name
2001-04-19 16:31:58 UTC
What does /etc/pam.d/xscreensaver and /etc/pam.d/system-auth say? /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 Is your password in /etc/shadow? I'm assuming you're *sure* you're typing it in right. 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). Fresh install or upgrade? (and what exact version of pam?) Also, do you have anything in /var/log/secure? 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? 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 Are you running the shipped kernel, or something else? If you're not running 2.4.2-2, please try that. I am running 2.4.4-pre4... I'll try redhat kernel! 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... 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). Actually, it appears to be a pam bug; it only works sort of by accident. 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. It's actually a race condition (sort of). unix_chkpwd is getting reaped by xscreensaver instead of by PAM. *** Bug 39174 has been marked as a duplicate of this bug. *** 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. 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! That is exactly what the problem is... that change exposes a pam problem. 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 The race condition is also triggered if you use kernel preemption. |