On Tue, Apr 22, 2008 at 11:54:19AM +0200, J?rg Barfurth wrote: > > I don't buy this "best compatibility" note. LinuxPAM fully supports > > PAM_IGNORE. > > But it appears to have interactions between pam_authenticate processing > and pam_setcred processing not seen in Solaris PAM. The one I recall is > that modules not called during pam_authenticate processing (due to a > preceding 'sufficient' success) are not called during pam_setcred > processing, even if the 'sufficient' module returns PAM_IGNORE now. > > Result is that pam_setcred fails because not a single PAM_SUCCESS return > has been seen in the shortened stack.
That's a problems on LinuxPAM. Let them provide a module that does the right thing if need be. > Additionally Linux-PAM has an extended control flags syntax that allows > specifying details of stack behavior for various return codes. As > pam_authenticate and pam_setcred share the auth entry (and thus the > control flag), returning a different result (including PAM_IGNORE) from > pam_sm_setcred than from pam_sm_authenticate may create behavior that > surprises users. We should not allow modules that return PAM_SUCCESS when they have done nothing. Especially account modules (fortunately that's not the problem here). > > It is a bug to return PAM_SUCCESS when the module has done nothing, and > > it can lead to misconfigurations that are difficult for customers to > > debug, and even to misconfigurations that result in security holes. > > > > Due to the scenario described above, I have a module that returns > PAM_IGNORE from pam_sm_setcred on Solaris, but had to be tweaked to > return PAM_SUCCESS on Linux. It looks as if the pam_radius_auth > developer had the same issue. But I also agree that returning anything > but PAM_IGNORE on Solaris, which doesn't have that pam_setcred > processing wart, is a bug. Exactly. So #ifdef this if you must. Nico --
