pam_succeed_if's pam_sm_setcred

[Ian Ward Comfort]

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