On Thu, 2004-07-29 at 16:56, W. Michael Petullo wrote:

Login, su, gdm is hanging on my system since I upgraded to pam-0.77-52 and selinux-policy-strict-1.15.8-3.

It looks like the hang is occuring when the pam_unix module is executed as an account module. Su/pam_unix executes unix_chkpwd, sets up a pipe and then reads from it. It seems that unix_chkpwd is failing to execute properly and su is hanging while it tries to read from the pipe. After a quick look at the code, I'm not convinced that pam_unix tests the exit value of unix_chkpwd properly.

Here is a strace of an su hang:

[...] pipe([3, 4]) = 0 rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x300313a8) = 4404 waitpid(4404, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 4404 --- SIGCHLD (Child exited) @ 0 (0) --- read(3, "12603:0:99999:7:-1:-1", 1023) = 21 read(3,

There is no problem when SELinux is not enforcing its strict policy. Unfortunately, I don't see any avc errors in my logs related to this.

I ran into the same bug. Try updating your pam package from Dan Walsh's site ftp://people.redhat.com/dwalsh/SELinux/Fedora/, as this seems to fix the behavior for me. I expect it will make its way into rawhide soon.

I think I can explain the lack of avc denied messages. There are dontaudit rules suppressing audit of attempts to access /etc/shadow directly by pam_unix, as it always tries to do that first. Then, if it fails, it falls back to running chkpwd. In permissive mode, the attempt to access /etc/shadow directly succeeds (since the process is uid 0), so pam_unix doesn't end up running chkpwd at all and you don't encounter the bug in the pam_unix code. In enforcing mode, the attempt to access /etc/shadow directly fails due to SELinux, but the audit is suppressed since this is expected, and it then runs the chkpwd helper. You then run into the bug in pam_unix itself, which causes the failure. So the SELinux denial is only indirectly related to the actual bug.