unix_chkpwd abnormal exit: 11 unix_chkpwd crashes under gnome-screensaver and prevents unlock (/dev/null corruption?)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pam (Fedora) |
Fix Released
|
Medium
|
|||
pam (Ubuntu) |
Triaged
|
High
|
Unassigned |
Bug Description
Binary package hint: libpam-modules
I am running Ubuntu Hardy 32-Bit on a Thinkpad T61 with all updates available today. The gnome screensaver locks my screen after 10 minutes idle automatically. Now in the password dialogue I can enter any password or string and the screen gets unlocked. In syslog you'll find the following error message simultaneously:
kernel: [32810.156696] unix_chkpwd[4787] general protection eip:b7f86446 esp:bfd2d31c error:0
But when I lock my screen manually, this bug doesn't occur and I have to type the right password to unlock the screen again.
Some more informations:
# lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
# apt-cache policy libpam-modules
libpam-modules:
Installed: 0.99.7.1-5ubuntu6.1
Candidate: 0.99.7.1-5ubuntu6.1
Version table:
*** 0.99.7.1-5ubuntu6.1 0
500 http://
100 /var/lib/
0.
500 http://
Jamie Strandboge (jdstrand) wrote : | #1 |
Changed in pam: | |
assignee: | nobody → jdstrand |
status: | New → Incomplete |
Thomas Babut (thbabut) wrote : | #2 |
In the meantime I've done a memory test over night and it passed without errors.
Hardware is a Thinkpad T61 with following components:
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HBM (ICH8M-E) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)
I am not using Compiz at all, so all desktop effects are disabled.
Jamie Strandboge (jdstrand) wrote : | #3 |
Can you post /var/log/syslog and /var/log/kern.log after the crash? What are the contents of /etc/pam.d/common-* and /etc/pam.
Steve Langasek (vorlon) wrote : | #4 |
The contents of /etc/pam.d/* are immaterial, here; we know that it's the unix_chkpwd process that's segfaulting, which means pam_unix must be involved. And I have seen bugs more recently whereby pam_unix will fail open if unix_chkpwd crashes unexpectedly; but the only case where I've /seen/ unix_chkpwd crash unexpectedly has been with a bug that post-dates the version in hardy.
So what would really help here is a backtrace of unix_chkpwd's crash.
Jamie Strandboge (jdstrand) wrote : | #5 |
We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!
Changed in pam: | |
assignee: | jdstrand → nobody |
status: | Incomplete → Invalid |
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #12 |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6) Gecko/2009020410 Fedora/3.0.6-1.fc10 (CK-IBM) (CK-IBM) Firefox/3.0.6
The screensaver lock option doesn't work anymore after a while.
After a normal startup/reboot, screen locking works fine, but after a while (I don't have a precise time or action) it doesn't work: screensaver works, but no password prompt is provided (it behaves like "Lock screen when screensaver is active" is unchecked).
Environment
-----------
Fedora 10 (Cambridge) up-to-date
[uname -a] Linux <hostname> 2.6.27.
[root@thoth ~]# rpm -qa | grep pam
pam_passwdqc-
pam_krb5-
pam_smb-
pam_ccreds-
pam-1.0.
pam_pkcs11-
gnome-keyring-
[root@thoth ~]#
Hardware: Lenovo T400 laptop
Components:
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
...
Related to this issue, audit log reports:
type=ANOM_ABEND msg=audit(
type=ANOM_ABEND msg=audit(
and /var/log/messages contains:
Mar 2 22:04:48 thoth kernel: unix_chkpwd[16059] general protection ip:83e978 sp:bfd12ea4 error:0 in ld-2.9.
Mar 2 22:04:48 thoth kernel: unix_chkpwd[16060] general protection ip:15c900 sp:bf9b3f84 error:0 in ld-2.9.
(I really need this feature to work since I'm working at the cust site, so I need to lock my screen from time to time. Thank you)
Reproducible: Always
Steps to Reproduce:
None.
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #13 |
You can make it public. It is a security related bug, but not a "Security Sensitive Bug". 10x
In Red Hat Bugzilla #488147, Vincent (vincent-redhat-bugs) wrote : | #14 |
Pasting your /etc/pam.
FWIW, I don't get this behaviour with F10/x86_64 using local authentication, and I didn't see it with a F10/x86 box using LDAP authentication.
As for a time "estimate", would you say it happens at least daily, or every few hours? More or less often?
In Red Hat Bugzilla #488147, Tomas (tomas-redhat-bugs) wrote : | #15 |
Also please attach the /etc/nsswitch.conf.
It would really help if you could get the backtrace from the crash although I am afraid that this will not be an easy task.
In Red Hat Bugzilla #488147, Tomas (tomas-redhat-bugs) wrote : | #16 |
I see 2 problems here:
1. the crash - I suppose this crash happens in some nss module (what is your glibc package version-release)?
2. pam_unix module doesn't guard against crash in unix_chkpwd - it should probably rather disallow access than allow it in case of the crash. Also when this problem with screensaver happens to you what happens when you try to login on the text console?
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #17 |
Hi Vincent, hi Tomas,
Thanks for the quick feedback. Here's the data requested:
$ cat /etc/pam.
#%PAM-1.0
auth required pam_shells.so
auth required pam_unix.so likeauth nullok try_first_pass
auth optional pam_ecryptfs.so unwrap
auth required pam_nologin.so
#
account required pam_unix.so
#
password optional pam_ecryptfs.so
password required pam_passwdqc.so min=disabled,
password sufficient pam_unix.so remember=8 nullok use_authtok md5 shadow
password required pam_deny.so
#
session required pam_limits.so
session required pam_unix.so
password optional pam_ecryptfs.so unwrap
session optional pam_console.so
[snap@thoth ~]$
I'm using local authentication.
This problem happens daily.
Later I'll try to find in which case it starts happening. When the problem starts I think only a reboot solve it (I'll check later if a logoff/logon is a workaround or not).
Glibc version is 2.9.3
$ rpm -q glibc
glibc-2.9-3.i686
$
I don't think that will affect the text console (I'll get back to you with other details if available).
Please tell me what else can I do to help you in this case. Again, thanks a lot for the feedback.
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #18 |
Oh, and the content of nsswitch.conf file also:
$ cat /etc/nsswitch.conf
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
# nisplus or nis+ Use NIS+ (NIS version 3)
# nis or yp Use NIS (NIS version 2), also called YP
# dns Use DNS (Domain Name Service)
# files Use the local files
# db Use the local database (.db) files
# compat Use NIS on compat mode
# hesiod Use Hesiod for user lookups
# [NOTFOUND=return] Stop searching if not found so far
#
# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd: db files nisplus nis
#shadow: db files nisplus nis
#group: db files nisplus nis
passwd: files
shadow: files
group: files
#hosts: db files nisplus nis dns
hosts: files mdns4_minimal [NOTFOUND=return] dns
# Example - obey only what nisplus tells us...
#services: nisplus [NOTFOUND=return] files
#networks: nisplus [NOTFOUND=return] files
#protocols: nisplus [NOTFOUND=return] files
#rpc: nisplus [NOTFOUND=return] files
#ethers: nisplus [NOTFOUND=return] files
#netmasks: nisplus [NOTFOUND=return] files
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files
netgroup: nisplus
publickey: nisplus
automount: files nisplus
aliases: files nisplus
$
In Red Hat Bugzilla #488147, Tomas (tomas-redhat-bugs) wrote : | #19 |
Do you have nscd enabled and running or not?
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #20 |
No, Tomas, the service is stopped.
# service nscd status
nscd is stopped
#
I'm having this problem almost all the time. Other interesting thing is that things are running fine after a reboot only (but not after a logoff/logon) and when exiting the screensaver it prompts me for a password or I can manually lock screen. But after a while I discovered that even if it is working (screensaver exists with the password dialog, if I let it run then the next screensaver exit place me back to the desktop without any password dialog.
This means that unix_chkpwd starts to crash on both cases: when I manually lock the screen (which starts the screensaver, but after pressing a key returns directly to the desktop) or when exiting the screensaver (pressing any key while running).
In case of a trace or something else, please provide me with the steps to follow and I'll try to provide you further details. Thank you.
In Red Hat Bugzilla #488147, Tomas (tomas-redhat-bugs) wrote : | #21 |
At the time the unix_chkpwd starts crashing in the screensaver can you try it to run manually:
echo -ne '<password>\0000' | /sbin/unix_chkpwd <user> nullok ; echo $?
Replace the <password> with the password of your account and the <user> with the user name.
Does it crash too? If it does, can you find any related entries in the audit log - use ausearch -x unix_chkpwd.
Does it still crash if you replace nullok with some bogus word? It should return 4 as exit value and add an audit entry and of course not crash.
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #22 |
Well, it doesn't crash in this case:
[snap@thoth ~]$ echo -ne '******\0000' | /sbin/unix_chkpwd snap nullok ; echo $?
0
[snap@thoth ~]$
Generally, When it crashes I get also the two aforementioned messages in /var/log/messages. Of course, it didn't crash in this case since no such messages were reported in messages log file. And audit log shows only old records about it, no current one:
# ausearch -i | grep unix_chkpwd | tail -n 5
type=ANOM_ABEND msg=audit(
type=ANOM_ABEND msg=audit(
type=ANOM_ABEND msg=audit(
type=USER_AUTH msg=audit(
type=ANOM_ABEND msg=audit(
#
When replacing nullok with some bogus word:
[snap@thoth ~]$ echo -ne 'id5n4pIT\0000' | /sbin/unix_chkpwd snap fakeword ; echo $?
bash: echo: write error: Broken pipe
4
[snap@thoth ~]$
indeed it returns 4 and no crash is reported: messages log file is clean and audit log reports:
type=ANOM_EXEC msg=audit(
That's it for now. Thanks again Tomas.
In Red Hat Bugzilla #488147, Tomas (tomas-redhat-bugs) wrote : | #23 |
Please download and install testing packages pam-1.0.
from http://
The unix_chkpwd will write debug messages to /var/log/secure when it runs.
What messages from unix_chkpwd do you see in /var/log/secure when the unix_chkpwd starts crashing?
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #24 |
Currently I have pam-1.0.
In Red Hat Bugzilla #488147, Tomas (tomas-redhat-bugs) wrote : | #25 |
The URL mentioned above does not point to a YUM repository. You have to download and install the pam-1.0.
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #26 |
Yes, but i need i386 version. I see only the debug version for X86_64. I'm using i386 so I need that version. Am I missing something?
$ uname -a
Linux thoth.<domain> 2.6.27.
$
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #27 |
Tomas, I do need to install pam-1.0.
In Red Hat Bugzilla #488147, Tomas (tomas-redhat-bugs) wrote : | #28 |
You can download them now from the http://
I had some problems building the i386 packages in mock.
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #29 |
Ok, so the debug version of pam is installed:
# rpm -ivh pam-1.0.
Preparing... #######
1:pam #######
Updating /etc/pam.
#
(the other package pam-debuginfo-
First case:
Having the system started from hibernate (which means the problem should still be there), using System > Lock Screen it blanks the screen, screensaver doesn't start (I've notice that in the past also, but that's not a problem anyway), leaving it a couple of seconds then pressing a key, here are the related messages in /var/log/secure:
Mar 5 20:59:50 thoth gnome-screensav
Mar 5 20:59:50 thoth gnome-screensav
Mar 5 20:59:50 thoth gnome-screensav
Indeed, there is no /lib/security/
Second case:
Now I was rebooting the system because I was curious how come it's working at the startup.
So it's simply working as it should. Now trying again to lock the screen, of course it's working (since again, after a normal startup or reboot is working for a while), and these are the debug messages generated:
Mar 5 21:21:12 thoth gnome-screensav
Mar 5 21:21:12 thoth gnome-screensav
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Started.
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Signals set up.
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Not at tty.
Mar 5 21:21:12 thoth unix_chkpwd[4763]: User from getuidname(): snap
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Passwords read: 1
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Hash obtained: 0
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Hash verified: 7
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Password verification result: 7
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Started.
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Signals set up.
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Not at tty.
Mar 5 21:21:19 thoth unix_chkpwd[4764]: User from getuidname(): snap
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Passwords read: 1
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Hash obtained: 0
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Hash verified: 0
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Password verification result: 0
Mar 5 21:21:19 thoth unix_chkpwd[4765]: Started.
Mar 5 21:21:19 thoth unix_chkpwd[4765]: Signals set up.
Mar 5 21:21:19 thoth unix_chkpwd[4765]: Not at tty.
Mar 5 21:21:19 thoth unix_chkpwd[4765]: User from getuidname(): snap
I didn't have the patience to wait for the issue to appear after reboot, so I installed
ecryptfs-
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #30 |
The issue started to happen again (alright, way later than it happend in the past, but it still happens). Messages related to it are the following:
- in /var/log/messages:
Mar 6 12:36:47 thoth kernel: unix_chkpwd[29542] general protection ip:468978 sp:bfea2c74 error:0 in ld-2.9.
Mar 6 12:36:47 thoth kernel: unix_chkpwd[29544] general protection ip:c40900 sp:bf9b0784 error:0 in ld-2.9.
-in /var/log/secure:
Mar 6 12:36:47 thoth gnome-screensav
- in the audit log:
type=ANOM_ABEND msg=audit(
type=ANOM_ABEND msg=audit(
I also installed pam-debuginfo package:
# rpm -ivh pam-debuginfo-
Preparing... #######
1:pam-debuginfo #######
#
but I think I should provide the debug versions in /etc/pam.
Should I do other changes as well to get further details?
Please advice. Thank you.
In Red Hat Bugzilla #488147, Tomas (tomas-redhat-bugs) wrote : | #31 |
Unfortunately the logs or rather nonexistence of any message from the unix_chkpwd in /var/log/secure means that the crash happens during the load of the shared libraries.
I'm reassigning the bug to glibc.
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #32 |
Hello,
Can somebody continue on this issue please?
As I said, I am willing to help on this problem since I really need to have this working properly. Thank you
In Red Hat Bugzilla #488147, Jakub (jakub-redhat-bugs) wrote : | #33 |
The crash is likely in __libc_
If a setuid/setgid/other AT_SECURE process is started without the standard file descriptors open (0, 1, 2), glibc during startup will try to open /dev/full on fd 0 and /dev/null on fd 1 and 2 (whichever is closed during exec), to avoid various exploits. The hlt insn is executed if it failed to open /dev/full resp. /dev/null, or if they aren't character devices, or if they don't have the expected major/minor number. So most likely after a while something screws up your /dev/null device, e.g. replaces it with a normal file or removes it etc.
The bug is in whatever corrupts /dev/null resp. /dev/full and partially in whatever starts suid/sgid binaries knowingly with one or more of the standard file descriptors closed.
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #34 |
Hi Jakub, very good info, thanks a lot for the feedback.
You are right, one of the apps (I need to find out which one) corrupts the /dev/null device. After recreating it as it should be, screen locking works again. :-)
# ls -l /dev/null
-rw-r--r-- 1 root root 0 2009-03-13 00:20 /dev/null
#
# rm -f /dev/null; mknod -m 666 /dev/null c 1 3
#
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 2009-03-13 00:21 /dev/null
#
And of course, since I still have pam-debug installed, this action is captured in /var/log/secure with the following info:
Mar 13 00:22:43 thoth unix_chkpwd[22656]: Started.
Mar 13 00:22:43 thoth unix_chkpwd[22656]: Signals set up.
Mar 13 00:22:43 thoth unix_chkpwd[22656]: Not at tty.
Mar 13 00:22:43 thoth unix_chkpwd[22656]: User from getuidname(): snap
Mar 13 00:22:43 thoth unix_chkpwd[22656]: Passwords read: 1
Mar 13 00:22:43 thoth unix_chkpwd[22656]: Hash obtained: 0
Mar 13 00:22:43 thoth unix_chkpwd[22656]: Hash verified: 7
Mar 13 00:22:43 thoth unix_chkpwd[22656]: Password verification result: 7
Mar 13 00:22:51 thoth unix_chkpwd[22662]: Started.
Mar 13 00:22:51 thoth unix_chkpwd[22662]: Signals set up.
Mar 13 00:22:51 thoth unix_chkpwd[22662]: Not at tty.
Mar 13 00:22:51 thoth unix_chkpwd[22662]: User from getuidname(): snap
Mar 13 00:22:51 thoth unix_chkpwd[22662]: Passwords read: 1
Mar 13 00:22:51 thoth unix_chkpwd[22662]: Hash obtained: 0
Mar 13 00:22:51 thoth unix_chkpwd[22662]: Hash verified: 0
Mar 13 00:22:51 thoth unix_chkpwd[22662]: Password verification result: 0
Mar 13 00:22:51 thoth unix_chkpwd[22663]: Started.
Mar 13 00:22:51 thoth unix_chkpwd[22663]: Signals set up.
Mar 13 00:22:51 thoth unix_chkpwd[22663]: Not at tty.
Mar 13 00:22:51 thoth unix_chkpwd[22663]: User from getuidname(): snap
In conclusion, I think I should run a small 'monitor' (maybe a simple C prog) to collect the list of processes from time to time, catch de change of /dev/null character device and compare the result to discover the culprit.
From your point of view, should I still leave pam-debug package in my system or not? I'm still willing to help in this case as long I don't brake the system: it's my main production laptop. ;-)
Thanks again. W4F.
In Red Hat Bugzilla #488147, Tomas (tomas-redhat-bugs) wrote : | #35 |
You can leave the debug packages in the system if you don't mind the excessive logging to /var/log/secure.
I will make an update package in Fedora soon anyway but of course you will still need to find out what application messes up the /dev/null.
In Red Hat Bugzilla #488147, Fedora (fedora-redhat-bugs) wrote : | #36 |
pam-1.0.4-2.fc9 has been submitted as an update for Fedora 9.
http://
In Red Hat Bugzilla #488147, Fedora (fedora-redhat-bugs) wrote : | #37 |
pam-1.0.4-2.fc10 has been submitted as an update for Fedora 10.
http://
In Red Hat Bugzilla #488147, Fedora (fedora-redhat-bugs) wrote : | #38 |
pam-1.0.4-2.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=
In Red Hat Bugzilla #488147, Fedora (fedora-redhat-bugs) wrote : | #39 |
pam-1.0.4-2.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #40 |
Package was updated on my system (together with this update, I removed pam-debug version). I've noticed that /dev/null didn't get corrupted anymore, although I didn't discover which app was doing it.
Now my question is: in case /dev/null becomes corrupted again (as a normal file instead of a char device), will I be able to login to my system? Or I have to reboot is or something to make it work?
Thanks for the feedback!
In Red Hat Bugzilla #488147, Tomas (tomas-redhat-bugs) wrote : | #41 |
I've tried to allow this but you should test this.
In Red Hat Bugzilla #488147, Fedora (fedora-redhat-bugs) wrote : | #42 |
pam-1.0.4-3.fc9 has been submitted as an update for Fedora 9.
http://
In Red Hat Bugzilla #488147, Fedora (fedora-redhat-bugs) wrote : | #43 |
pam-1.0.4-3.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=
In Red Hat Bugzilla #488147, Fedora (fedora-redhat-bugs) wrote : | #44 |
pam-1.0.4-3.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=
In Red Hat Bugzilla #488147, Fedora (fedora-redhat-bugs) wrote : | #45 |
pam-1.0.4-4.fc9 has been submitted as an update for Fedora 9.
http://
In Red Hat Bugzilla #488147, Fedora (fedora-redhat-bugs) wrote : | #46 |
pam-1.0.4-4.fc10 has been submitted as an update for Fedora 10.
http://
In Red Hat Bugzilla #488147, Fedora (fedora-redhat-bugs) wrote : | #47 |
pam-1.0.4-4.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=
In Red Hat Bugzilla #488147, Fedora (fedora-redhat-bugs) wrote : | #48 |
pam-1.0.4-4.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=
Michael Tokarev (mjt+launchpad) wrote : | #6 |
This is in fact reproduceable. I had the same issue too, was difficult to debug (due to setuid-ness of the binary in question), but finally it turned out to be wrong permissions for /dev/full (local config error really) - it was 0660 instead of 0666, so unix_chkpwd was unable to open it when run from user, and complained.
So, we've quite several issues here.
1) some programs (xscreensaver is one) executes PAM stuff with (some) standard filedescriptors closed. Not that it's an issue by itself, but it MAY lead to some unexpected results like this one, and is somewhat unsafe too.
2) wrong logic in calling unix_chkpwd helper from pam_unix. This is a security issue and is a significant one. Failure to verify the password gets interpreted as success. How about running *almost* out of processes and calling some su(1) to expect unix_chkpwd to fail?
3) wrong logic in unix_chkpwd itself, it should not crash if it's unable to reopen its standard file descriptros.
Oh well.
I'd bot close this bug given the above.
See also fedora bug report of the same nature -- https:/
In Red Hat Bugzilla #488147, Fedora (fedora-redhat-bugs) wrote : | #49 |
pam-1.0.4-4.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
In Red Hat Bugzilla #488147, Fedora (fedora-redhat-bugs) wrote : | #50 |
pam-1.0.4-4.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
In Red Hat Bugzilla #488147, Marius (marius-redhat-bugs) wrote : | #51 |
The app that corrupted /dev/null is Vodafone Mobile Connect client, installed with the package vodafone-
I have pam updated to the latest version: pam-1.0.
Now, testing again by corrupting /dev/null char device:
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 2009-04-18 14:59 /dev/null
#
# rm -f /dev/null; touch /dev/null; ls -l /dev/null
-rw-r--r-- 1 root root 0 2009-04-20 15:04 /dev/null
#
"Lock Screen" works fine! No related messages are generated in /var/log/messages or /var/log/secure. I just created back the device as designed:
# ls -l /dev/null
-rw-r--r-- 1 root root 0 2009-04-20 15:04 /dev/null
#
# rm -f /dev/null; mknod -m 666 /dev/null c 1 3
#
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 2009-04-20 15:12 /dev/null
#
I consider this problem solved!
Again, thank you very much for the support and the quick feedback. It was a pleasure to help the community support to improve the experience!
Keep up the good work!
Changed in pam (Ubuntu): | |
importance: | Undecided → High |
status: | Invalid → Triaged |
Chris Weiss (cweiss) wrote : | #7 |
I am having this issue on a lucid x64 install upgraded from a properly working karmic. I have another lucid x64 clean install that does not have the issue.
the only information I have is this in my auth.log. can I enable some extended login somehow?
Apr 18 16:27:29 cw gnome-screensav
Apr 18 16:27:31 cw gnome-screensav
Apr 18 16:27:31 cw gnome-screensav
there's 2 because i tried 2 times to make sure I didn't typo, then switched to console and logged in to kill gnome-screensaver. This also isn't failing intermittently, it fails every time, even when manually locking the screen.
H.-Dirk Schmitt (dirk-computer42) wrote : | #8 |
Is /dev/null corrupted (see https:/
This can trigger this bug.
Paul Sladen (sladen) wrote : | #9 |
Some of the dups/link suggest that the pam_unix abnormal exit (crash) is down to corruption of /dev/null, possibly caused by a rogue version of the Vodafone Mobile Connect client.
It could be that this is being shipped (at least in the case of one of the dups) but a netbook distributor along with UNR/UNE.
summary: |
- unix_chkpwd crashes on gnome-screensaver + unix_chkpwd abnormal exit: 11 unix_chkpwd crashes under gnome- + screensaver |
summary: |
- unix_chkpwd abnormal exit: 11 unix_chkpwd crashes under gnome- - screensaver + unix_chkpwd abnormal exit: 11 unix_chkpwd crashes under gnome- + screensaver and prevents unlock |
summary: |
unix_chkpwd abnormal exit: 11 unix_chkpwd crashes under gnome- - screensaver and prevents unlock + screensaver and prevents unlock (/dev/null corruption?) |
Chris Cowan (macil) wrote : | #10 |
I had this problem, and it turned out I had chown'ed /etc/shadow as root:root instead of root:shadow. I was really confused because my password worked fine for logging in normally and for ssh, but just not for the screensaver.
Steve Langasek (vorlon) wrote : | #11 |
https:/
And fds 1 and 2 are closed by pam_unix before launching unix_chkpwd, which is what triggers the abort.
Ultimately the bug is in whatever has broken the standard devices on the system, preventing the fds from being reopened. But we may be able to defend against this better by just not closing stdout/stderr in the first place.
security vulnerability: | yes → no |
Changed in pam (Fedora): | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |
I cannot reproduce this on an up to date hardy i386 virtual machine with the same package versions. I even tried a small test program that just runs unix_chkpwd with various input and it works fine. Can you run 'memtest' to make sure your memory is ok? Can you provide more details on your setup?