Nicolas Williams schrieb: > On Mon, Apr 21, 2008 at 02:06:52PM -0700, Darren J Moffat wrote: >> Implementation Notes >> -------------------- >> The module only supports the auth stack. pam_sm_setcred(3PAM) returns >> the same value as pam_sm_authenticate(3PAM) returned or PAM_SUCCESS >> if pam_sm_setcred(3PAM) was called without pam_sm_authenticate(3PAM). >> This isn't ideal as pam_sm_setcred(3PAM) should probably always return >> PAM_IGNORE - comments in the code indicate that the upstream project >> team is aware of this but wants "best compatibility" across all >> PAM implementations. > > 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. 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. > 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. - J?rg -- Joerg Barfurth Software Engineer mailto:joerg.barfurth at sun.com Desktop Technology Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
