On 5 Mar 2009, at 4:34 PM, Ian Ward Comfort wrote:
I found the problem, thanks to your pointer. My pam_authenticate
stack is skipping the module, but the stack is being navigated in an
sshd privsep child. When the pam_setcred stack runs later, in the
parent process, the child's state is of course lost, so the whole
stack is re-run with no cached retvals and use_cached_chain ==
_PAM_MAY_BE_FROZEN.
(Actually, the same thing happens without privilege separation on my
RHEL 5.3 system; I'm not sure what's happening with the pthreads
there.)
The answer is: nothing was happening with any pthreads; my sshd was
simulating threads with forked processes (as is standard,
apparently). So with or without privilege separation, OpenSSH's sshd
runs pam_authenticate in its own process, which dies before
pam_setcred is run in the parent process.
So, it looks like in this case, making pam_succeed_if's
pam_sm_setcred functional would actually provide the behavior I
want. However it also appears that _PAM_MAY_BE_FROZEN is only
intended for backward compatibility, so perhaps the fix should
really be to OpenSSH, or my distro's build of it.
Linux-PAM is the only PAM software I can find which does stack
freezing, which makes me think that it will have to support this call
order for portable applications for a long time to come. If that's
so, would a functional pam_sm_setcred like this cause any problems?
(To be maximally compatible, pam_succeed_if could save a note to
itself in pam_sm_authenticate and return PAM_IGNORE from
pam_sm_setcred if it has already run, but perform the requested logic
if it hasn't.)
--
Ian Ward Comfort <icomfort@xxxxxxxxxxxxxxxxxxxx>
System Administrator, Student Computing, Stanford University
_______________________________________________
Pam-list mailing list
Pam-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/pam-list
