I have recently updated the pam rpm on my FC4 machine from: pam-0.79-8 to pam-0.79-9.1 The machine was orginally built as FC3 running SELinux strict/enforcing, upgraded to FC4, "/.autorelabel"'ed, and thereafter gradually patched up with FC4 updates using yum. The SELinux policy is using: selinux-policy-strict-1.23.16-6 The current pam misbehaviour for a variety of authentication sequences is as follows: ======================================== With SELinux enforcing and pam-0.79-9.1: "su -" works Ok. ( both su-ing to root and non-root users. ) "sudo" fails every time with: sudo: pam_authenticate: System error "/bin/login" fails every time with only these messages in syslog: Jul 25 08:45:31 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr, System error Jul 25 08:45:31 topaz kernel: audit(1122277531.083:24): avc: denied { lock } for pid=5704 comm="login" name="btmp" dev=hda7 ino=339558 scontext=system_u:system_r:local_login_t tcontext=system_u:object_r:faillog_t tclass=file "ssh localhost" fails every time with: Jul 25 08:48:31 topaz sshd[14927]: error: Could not get shadow information for ejtr Jul 25 08:48:31 topaz sshd[14927]: Failed password for ejtr from 127.0.0.1 port 50117 ssh2 ========================================= With SELinux permissive and pam-0.79-9.1: "su -" works Ok. ( both su-ing to root and non-root users. ) "sudo" fails 1st time with: sudo: pam_authenticate: System error and then succeeds 2nd time - but still asks for password. On the 3rd attempt it caches the authentication from the 2nd attempt and works Ok. "/bin/login" appears to fail twice and then succeed. Jul 25 08:53:07 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr, System error Jul 25 08:53:07 topaz kernel: audit(1122277987.276:26): avc: denied { lock } for pid=5767 comm="login" name="btmp" dev=hda7 ino=339558 scontext=system_u:system_r:local_login_t tcontext=system_u:object_r:faillog_t tclass=file Jul 25 08:53:11 topaz login: FAILED LOGIN SESSION FROM (null) FOR ejtr, System error Jul 25 08:53:11 topaz kernel: audit(1122277991.339:27): avc: denied { lock } for pid=10278 comm="login" name="btmp" dev=hda7 ino=339558 scontext=system_u:system_r:local_login_t tcontext=system_u:object_r:faillog_t tclass=file Jul 25 08:53:15 topaz login(pam_unix)[10621]: session opened for user ejtr by (uid=0) Jul 25 08:53:15 topaz -- ejtr[10621]: LOGIN ON tty2 BY ejtr Jul 25 08:53:19 topaz login(pam_unix)[10621]: session closed for user ejtr Jul 25 08:53:25 topaz login(pam_unix)[11502]: session opened for user ejtr by (uid=0) Jul 25 08:53:25 topaz -- ejtr[11502]: LOGIN ON tty2 BY ejtr Jul 25 08:53:27 topaz login(pam_unix)[11502]: session closed for user ejtr "ssh localhost" works 1st time. =============================================== When I saw the "shadow" error on sshd, I tried adding some "debug" to SELinux policy to double check that the correct domain was trying to read shadow_t. That proved to be a red-herring, as did tracking the lock access denial on /var/log/btmp. I've checked SELinux file_contexts on the pam installed files - seems Ok. I've tried downgrading pam to 0.79-8 and back to 0.79-9.1 again. The system consistently works every time with 0.79-8 and misbehaves every time with 0.79-9.1 Amongst the trail of debugging, I've found a couple of pam errors which are seemingly unrelated to the overall failure, but probably need fixing: This: allow crond_t self:capability { audit_control } ; seems to be needed to allow per-user crontab's to audit correctly. There seems to be some inconsistency in the use and non-use of pam_loginuid.so and pam_selinux.so in /etc/pam.d/XXXX as between /etc/pam.d/su /etc/pam.d/sudo /etc/pam.d/login /etc/pam.d/gdm /etc/pam.d/sshd I would have thought that most, if not all, of the pam.d configurations should have pam_loginuid.so and pam_selinux.so references, but I could so easily be wrong about this. I also noticed that the FC3 -> FC4 upgrade process failed to automatically install the "audit" rpm. I manually added it via yum whilst tracking the pam problem, but the lack of the auditd service also seems to be a red-herring. I currently have it installed but chkconfig'ed off - mainly so as to ensure all the logs are in one place for ease of debugging. I've tried temporarily disabling various clauses in /etc/pam.d/login - such as pam_console - to try and isolate the issue, but I haven't had much luck with that either. With "debug" enabled on the pam_stack.so entry in /etc/pam.d/login, it seems that "system-auth" always returns SUCCESS, which seems to eliminate most of pam as a source of error. Can anyone throw any light on the problem or give me some other ideas for debugging the issue? Thanks, -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list