--On Tuesday, April 22, 2008 11:54:19 AM +0200 J?rg Barfurth <Joerg.Barfurth at Sun.COM> wrote:
>> I don't buy this "best compatibility" note. LinuxPAM fully supports >> PAM_IGNORE. True. > 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. Correct. Linux-PAM calls exactly the same set of modules in pam_setcred as were called in pam_authenticate, in exactly the same order. The results do not affect the flow of control (with the possible exception of aborting the stack as for failure of a 'required' module; I don't remember). > Result is that pam_setcred fails because not a single PAM_SUCCESS return > has been seen in the shortened stack. Hrm. It seems to me that a module that returned PAM_SUCCESS in the pam_authenticate processing should probably not return PAM_IGNORE in setcred. Of course, Linux-PAM has configuration syntax that allows more or less arbitrary mapping from the module's return status to the action that is actually taken, so if this situation does occur, it is possible to work around. >> 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. Perhaps, but I don't think I buy it. In fact, as I understand it the _reason_ Linux-PAM has the aforementioned "wart" is to prevent problems due to results returned in pam_setcred processing being used for flow control. Note that the purpose of pam_setcred is to make the user's credentials available to whatever session is being started. It should never be the case that an unexpected successful return value from pam_setcred would "result in security holes", because the return value from pam_setcred should not be being used to make any security decisions. Once pam_setcred is called, the decision has already been made to let the user in. Nico wrote: > That's a problems on LinuxPAM. Let them provide a module that does the > right thing if need be. So, the upstream in question is FreeRADIUS, not Linux-PAM and not any particular Linux group. It is entirely reasonable for the FreeRADIUS people to want to maintain compatibility with as many PAM implementations as possible. It is unfortunate that the various PAM implementors have been unable to get together and agree on a common API (and no, there is not a common API, because an API is more than just a set of function signatures; it includes things like the disagreement over whether PAM applications should have to be privileged). However, that is not the fault of the maintainers of the module in question. For folks like the FreeRADIUS developers, or myself, maintaining cross-platform portability is much more important than adhering to any one OS vendor's vision of how the world ought to be. -- Jeff
