[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

X crashes in flames on SuSE 7.1 using pam_console.so

Hello all-

In spite of having read through documentation at
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html, and
http://www.redhat.com/support/wpapers/newpam/index.html, I'm having an
extremely difficult time solving a strange interaction that seems to be
happening between PAM, X, and a military simulation system that is being
developed for Redhat Linux called JCATS (Joint Combat And Tactical
Simulation System).  Although I know you won't be able to help with the
JCATS software (I'm working with the developer of that software too), I'm
hoping that you might be able to give me some insight with this problem as
it seems to involve PAM and /lib/security/pam_console.so (that is, I think
if I tweak pam somehow, then JCATS will work fine).

My system is a SuSE 7.1 system.

The problem seems to involve these files:

root@innovate:/etc/pam.d > ls -l xserver*
lrwxrwxrwx    1 root     root           25 Jul 11 05:54 xserver ->
-rw-r--r--    1 root     root          156 Mar 23  2000 xserver.jcatsd
-rw-r--r--    1 root     root          157 Sep 24  1999 xserver.redhat
lrwxrwxrwx    1 root     root           25 Jul 11 04:38 xserver.rpmsave ->
-rw-r--r--    1 root     root          157 Sep 24  1999 xserver.sav
root@innovate:/etc/pam.d >

My SuSE distribution didn't come with an xserver file of any sort in
/etc/pam.d/.  The JCATS software puts these 3 files and 2 symlinks here as a
part of its installation process.  JCATS will not run properly without these
files in /etc/pam.d/, but with them present, when I execute a certain
command in JCATS, the X server and all applications running in it (including
JCATS) are all immediately killed, the runlevel for the machine immediately
changes to 3 and then comes back to 5 with a kdm prompt.  What's so
surprising to me about this bizarre failure is that I am running JCATS as a
normal user (without root privileges).  I was under the impression that only
root could change runlevels.  If the files are absent from /etc/pam.d/, then
the X server does not die; JCATS simply complains about the files being
absent and tells me it won't run without them.

I've tried using several different versions of PAM, starting with the
version that came installed with SuSE 7.1.  That didn't work, because my
default PAM installation has no pam_console.so module, and the JCATS
software calls that module.

I'm now using PAM from a Polish(ed) Linux Distribution
4.3-1.i686.rpm) because my default PAM installation from SuSE has no
pam_console.so module and the one from Polish(ed) Linux Distribution does
have it.  However, in the white paper that I point to above, the author
mentions the files: /etc/security/console.perms and
/etc/security/console.apps/.  My default installation of PAM came with no
console.perms file.  It does (and did) have a
/etc/security/console.apps/ directory, and has no files within that
directory (which I understand to mean that no services will have root
privileges from the console unless root is logged in and that suits me

The contents of the 3 non-symlink files above are as follows:

root@innovate:/etc/pam.d > cat xserver.jcatsd
auth       sufficient   /lib/security/pam_rootok.so
auth       required     /lib/security/pam_permit.so
account    required     /lib/security/pam_permit.so
root@innovate:/etc/pam.d > cat xserver.redhat
auth       sufficient   /lib/security/pam_rootok.so
auth       required     /lib/security/pam_console.so
account    required     /lib/security/pam_permit.so
root@innovate:/etc/pam.d > cat xserver.sav
auth       sufficient   /lib/security/pam_rootok.so
auth       required     /lib/security/pam_console.so
account    required     /lib/security/pam_permit.so
root@innovate:/etc/pam.d >

The strange thing is that even if the files have no content, the bizarre
killing of the X server and changing of runlevels still happens when I
execute the JCATS command (I don't suspect the JCATS software as the culprit
because I know it runs on Redhat machines without this problem).

In case this information is important, I include the following:

root@innovate:/lib > ls -l libpam*
lrwxrwxrwx    1 root     root           16 Jul 11 05:44 libpam.so.0 ->
-rwxr-xr-x    1 root     root        29556 Jun 17 14:51 libpam.so.0.74.0
lrwxrwxrwx    1 root     root           21 Jul 11 05:44 libpam_misc.so.0 ->
-rwxr-xr-x    1 root     root         8668 Jun 17 14:51
lrwxrwxrwx    1 root     root           17 Jul 11 05:44 libpamc.so.0 ->
-rwxr-xr-x    1 root     root        10088 Jun 17 14:51 libpamc.so.0.74.0
root@innovate:/lib > cd /usr/lib
root@innovate:/usr/lib > ls -l libpam*
lrwxrwxrwx    1 root     root           26 Jul 11 05:47 libpam.so ->
-rw-r--r--    1 root     root         6652 Jan 19 00:45 libpam_misc.a
lrwxrwxrwx    1 root     root           31 Jul 11 05:46 libpam_misc.so ->
lrwxrwxrwx    1 root     root           27 Jul 11 05:46 libpamc.so ->
root@innovate:/usr/lib > rpm -q pam
root@innovate:/usr/lib > 

Through experimentation, I have found that the file /etc/pam.d/xserver is
critically involved in the bizarre crash.  If it is not present in
/etc/pam.d/ then no crash occurs.  More specifically:

1) if only /etc/pam.d/xserver.jcatsd is present (and no other xserver* files
are in /etc/pam.d/), then JCATS complains but there is no crash of X and
changing of runlevels;

2) if only /etc/pam.d/xserver.redhat is present and no other xserver* files
are in /etc/pam.d/), then JCATS complains but there is no crash of X and
changing of runlevels; 

3) but if both xserver.jcatsd and xserver.redhat are present in /etc/pam.d/
then apparently the JCATS software takes note of this, makes its own symlink
/etc/pam.d/xserver->/etc/pam.d/xserver.redhat, and then crashes in flames,
killing the X server and changing the runlevels and everything.
Interestingly, this behavior occurs even if these two files have no content
(zero-byte files).

I'm guessing (based upon what I've read in the white paper about what
pam_console does), that the JCATS software needs access to some console
devices, but the JCATS people have not yet told me exactly what their
software needs access to.

I have tried installing a standard /etc/security/console.perms file with
permissions of 644 (copy pasted below), as well as the console.perms file
that the JCATS development people are using (it is identical to the standard
Redhat console.perms file) and I still have the same bizarre crashing

# /etc/security/console.perms
# This file determines the permissions that will be given to priviledged
# users of the console at login time, and the permissions to which to
# revert when the users log out.

# format is:
#   <class>=list of regexps specifying consoles or globs specifying files
#   file-glob|<class> perm dev-regex|<dev-class> \
#     revert-mode revert-owner[.revert-group]
# the revert-mode, revert-owner, and revert-group are optional, and default
# to 0600, root, and root, respectively.
# For more information:
# man 5 console.perms

# file classes -- these are regular expressions
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9]
<xconsole>=:[0-9]\.[0-9] :[0-9]

# device classes -- these are shell-style globs
<floppy>=/dev/fd[0-1]* \
	 /dev/floppy/* /mnt/floppy*
<sound>=/dev/dsp* /dev/audio* /dev/midi* \
	/dev/mixer* /dev/sequencer \
	/dev/sound/* /dev/beep \
        /dev/admm* \
	/dev/adsp* /dev/aload* /dev/amidi* /dev/dmfm* \
	/dev/dmmidi* /dev/sndstat
<jaz>=/dev/jaz /mnt/jaz*
<zip>=/dev/zip /mnt/pocketzip* /mnt/zip*
<ls120>=/dev/ls120 /mnt/ls120*
<camera>=/dev/camera /mnt/camera*
<memstick>=/dev/memstick /mnt/memstick*
<flash>=/dev/flash /mnt/flash*
<fb>=/dev/fb /dev/fb[0-9]* \
<v4l>=/dev/video* /dev/radio* /dev/winradio* /dev/vtx* /dev/vbi* \
      /dev/video/* /dev/vttuner
<dri>=/dev/nvidia* /dev/3dfx*
<burner>=/dev/scd* /dev/sg* /dev/pcd* /dev/pg* /dev/cdwriter
<usb>=/dev/usb/dabusb* /dev/usb/dc2xx* /dev/usb/mdc800* /dev/usb/rio500
/dev/usb/scanner* /dev/usb/ttyUSB*

# permission definitions
<console>  0660 <serial>     0660 root.tty
<console>  0660 <floppy>     0660 root.floppy
<console>  0600 <sound>      0600 root.audio
<console>  0600 <cdrom>      0660 root.cdrom
<console>  0600 <pilot>      0660 root.uucp
<console>  0600 <jaz>        0660 root.disk
<console>  0600 <zip>        0660 root.disk
<console>  0600 <ls120>      0660 root.disk
<console>  0600 <scanner>    0600 root
<console>  0600 <camera>     0600 root
<console>  0600 <memstick>   0600 root
<console>  0600 <flash>      0600 root
<console>  0600 <fb>         0600 root
<console>  0600 <kbd>        0600 root
<console>  0600 <joystick>   0600 root
<console>  0600 <v4l>        0600 root.sys
<console>  0700 <gpm>	     0700 root
<console>  0600 <mainboard>  0600 root
<console>  0660 <burner>     0660 root.cdwriter
<console>  0600 <usb>        0660 root.usb

<xconsole> 0600 /dev/console 0600 root.root
<xconsole> 0600 <dri>	     0600 root

I even tried a different console.perms file from the redhat ftp server at:


This causes the same symptoms.

Does anyone have any thoughts on why this might be occurring and how to fix

I know that SuSE has made it's own enhancements to the X server.  Could that
be causing this strange interaction?

Thanks in advance for any thoughts.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []