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.
--
Stephen Smalley <sds@xxxxxxxxxxxxxx>
National Security Agency
