After upgrading to udev on a pam-enabled system, I get the following error on boot: * Cleaning /var/lock, /var/run... [ ok ] getgrnam failed for usb /sbin/rc: line 529: 5557 Segmentation fault /sbin/pam_console_appl [ ok ] * Cleaning /tmp directory... [ ok ] And, shutdown freezes after: * Bringing lo down... [ ok ] Running a ps when shutdown is in this state reveals that /sbin/pam_console_apply -r is running. Killing this process allows shutdown to complete normally. I don't know enough about either pam or udev to figure out why they're not playing nice with one another. Reproducible: Always Steps to Reproduce: 1. reboot Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.3-gentoo-r2) ================================================================= System uname: 2.6.3-gentoo-r2 i686 AMD Athlon(tm) XP 1800+ Gentoo Base System version 1.4.3.13p1 distcc 2.12.1 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://www.gtlib.cc.gatech.edu/pub/gentoo http://mirrors.tds.net/gentoo http://csociety-ftp.ecn.purdue.edu/pub/gentoo/ http://gentoo.seren.com/gentoo http://ftp.heanet.ie/pub/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow X aalib alsa apache2 avi berkdb bonobo cdr crypt cups dga directfb dvd encode esd fbcon foomaticdb gdbm gif glut gnome gtk gtk2 gtkhtml guile imap imlib java jpeg libg++ libwww mad maildir mikmod mmx motif mozcalendar mozilla moznocompose moznoirc mozsvg mozxmlterm mpeg ncurses nptl oggvorbis opengl pam pdflib perl plotutils png ppds python quicktime readline ruby samba scanner sdl slang spell ssl svga tcltk tcpd tetex tiff truetype usb x86 xml2 xmms xv zlib"
More hints: I found this in /etc/init.d/bootmisc: # Reset pam_console permissions [ -x /sbin/pam_console_apply -a ! -c /dev/.devfsd ] && \ /sbin/pam_console_apply -r It looks like it means "if you're using devfs, do NOT run the pam_console_apply script." Maybe the script shouldn't be run for udev either?
[ -x /sbin/pam_console_apply -a ! -c /dev/.devfsd ] && \ /sbin/pam_console_apply -r means, if there is pam_console_apply and excutable, and if there is no /dev/.devfsd or it's not character, then run /sbin/pam_console_apply -r. so a user who use devfs have /dev/.devfsd and shoun't execute /sbin/pam_console_apply -r. and other user should execute it.
So, why if you are using udev would you want to run "/sbin/pam_console_apply -r"? What does it do that devfs takes care of on its own?
I don't know. Like I said I don't have expertise with PAM. However, the startup and shutdown scripts both try to execute pam_console_apply -r. Shouldn't a segfault be reported upstream, too?
Have a look at the pam_console_apply manual. It looks to me as though pam_console_apply is trying to reset permissions on shutdown, but maybe some of the devices in /etc/security/console.perms don't exist, and a bug prevents it from executing properly. Seems like a pam bug to me. Also, as far as I know, udev has its own way of handling device permissions on bootup/shutdown, so if you're not using devfs, using pam_console_apply isn't necessary.
> Seems like a pam bug to me. Agreed. Does anyone know where to report this upstream? I tried pam-list to no avail, and the most appropriate bugzilla I can find is redhat's which looks very fedora-specific. > Also, as far as I know, udev has its own way of handling device permissions on > bootup/shutdown, so if you're not using devfs, using pam_console_apply isn't > necessary. Yeah, I commented out the lines that were calling it on bootup/shutdown. Maybe there should be a test for udev, similar to the test for devfs, that disables calling pam_console_apply for udev systems? Thanks for your insights!
already fixed in baselayout-1.11.3+ ... take this upstream if you care to ;) *** This bug has been marked as a duplicate of 50315 ***
The segfault is caused by a Gentoo patch: pam-0.77-patches/gentoo-patches/pam-0.77-console-reset.patch do not report upstream!
