[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pam_succeed_if's pam_sm_setcred



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 rescomp stanford edu>
System Administrator, Student Computing, Stanford University


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]