Nicolas Williams wrote: > > This is not the case. > > It sure is on Solaris PAM. And you've told me that Linux-PAM 0.75 will > call a module's setcred() even that module's authenticate() returned > PAM_IGNORE. If the module returns PAM_IGNORE the first time through, the rules I've explained will guarantee that it is called in the cred stack. Basically, if its called in the 'auth' stack, it will get called in the 'cred' stack. > I think having a module's setcred() be called EVEN if its authenticate() > was not IS useful: it gives the module a way to find out that the user > was successfully authenticated by PAM even though it (the module) was > not involved. There are other ways to do this, notably with an entry of this form at the top of the authentication stack: auth optional pam_foo.so no-op auth <stuff as before> It is the way it is to properly support the chained PAM stacks, and keep the implementation relatively clean. [...] > Why password? I can understand session... pam_sm_password() is called twice. Once [PAM_PRELIM_CHECK] to prepare for setting the password (and ping necessary servers etc.) and then, if the stack as a whole returned success this first time, the stack is invoked for a second time [PAM_UPDATE_AUTHTOK]. The point being to force the stack to follow the same path the second time through. > I think suuficient in auth should become optional in setcred, everything > else should remain as in auth, and ALL auth modules should have their > setcred() be called... Could you give some examples of why this makes more sense than a simple 'required/optional' scheme? > > auth [success=2, default=reset] pam_user_in_arglist.so me you him her > > auth requisite pam_unix.so > > auth sufficient pam_permit.so > > Oh. Is this documented? I don't follow this example as it is... I.e., http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-4.html#ss4.1 > where is the fork? Is the success=2 a "skip 2 if success" directive?? If Yes. > so, I'd love that sort of thing -- I might even write a patch for > Solaris PAM and submit it to sun in an RFE... This idea actually came from Vipin (half author of the original DCE RFC for PAM) from Sun. Cheers Andrew