Hello all- In spite of having read through documentation at http://www.linuxdoc.org/HOWTO/User-Authentication-HOWTO/index.html, 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 -> /etc/pam.d/xserver.redhat -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 -> /etc/pam.d/xserver.redhat -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 (ftp://speakeasy.rpmfind.net/linux/PLD/current/PLD-1.0/i686/PLD/RPMS/pam-0.7 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 fine). The contents of the 3 non-symlink files above are as follows: root@innovate:/etc/pam.d > cat xserver.jcatsd #%PAM-1.0 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 #%PAM-1.0 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 #%PAM-1.0 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 -> libpam.so.0.74.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 -> libpam_misc.so.0.74.0 -rwxr-xr-x 1 root root 8668 Jun 17 14:51 libpam_misc.so.0.74.0 lrwxrwxrwx 1 root root 17 Jul 11 05:44 libpamc.so.0 -> libpamc.so.0.74.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 -> ../../lib/libpam.so.0.74.0 -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 -> ../../ lib/libpam_misc.so.0.74.0 lrwxrwxrwx 1 root root 27 Jul 11 05:46 libpamc.so -> ../../lib/libpamc.so.0.74.0 root@innovate:/usr/lib > rpm -q pam pam-0.74.3-1 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 behavior. ======================= # /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 <serial>=/dev/ttyS* <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 <cdrom>=/dev/cdrom* <pilot>=/dev/pilot <jaz>=/dev/jaz /mnt/jaz* <zip>=/dev/zip /mnt/pocketzip* /mnt/zip* <ls120>=/dev/ls120 /mnt/ls120* <scanner>=/dev/scanner <camera>=/dev/camera /mnt/camera* <memstick>=/dev/memstick /mnt/memstick* <flash>=/dev/flash /mnt/flash* <fb>=/dev/fb /dev/fb[0-9]* \ /dev/fb/* <kbd>=/dev/kbd <joystick>=/dev/js* <v4l>=/dev/video* /dev/radio* /dev/winradio* /dev/vtx* /dev/vbi* \ /dev/video/* /dev/vttuner <gpm>=/dev/gpmctl <dri>=/dev/nvidia* /dev/3dfx* <mainboard>=/dev/apm_bios <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: ftp://ftp.redhat.com/pub/redhat/redhat-6.2-en/os/i386/RedHat/RPMS/pam-0.72-6 .i386.rpm This causes the same symptoms. Does anyone have any thoughts on why this might be occurring and how to fix it? 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. Regards, Kevin
