First, let me say thanks for this long email! I think you've done more than anyone in a long while to get to the bottom of the setcred issue. David MacKenzie wrote: > 6. The pam_sm_setcred() functions for modules that authenticated > successfully might not get called. This problem was discovered by > one of the FreeBSD developers, Jacques A. Vidrine <n@nectar.com>. > Consider the following pam.conf section: This is not exactly new - its actually documented in the module writer's guide: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_modules-3.html#ss3.2 > login auth sufficient pam_skey.so > login auth sufficient pam_krb5.so > login auth required pam_unix.so > > Here's what happens with Linux-PAM when you enter a krb5 password: > > application: pam_authenticate() > libpam: pam_dispatch() > pam_skey: pam_sm_authenticate() /* fail */ > pam_krb5: pam_sm_authenticate() /* success */ > application: pam_setcred() > libpam: pam_dispatch() > pam_skey: pam_sm_setcred() /* success */ > pam_krb5: /* not called */ > > In contrast, my experiments show that the Solaris 8 libpam calls the > pam_sm_setcred() function for all of the auth modules defined in > pam.conf for the current service. A module should store whatever state > it needs using pam_set_item() in pam_sm_authenticate(), and in > pam_sm_setcred() if it can't pam_get_item() that information back, > just return PAM_SUCCESS (or perhaps PAM_IGNORE) indicating that it's > punting, no-op, nothing to do here move along now.... The problem with this is that the stacking thing gets very confused in this case. (BTW I think you mean pam_[sg]et_data() here.) Linux-PAM has an extended syntax for the control token ('sufficient' etc.) that was actually suggested by Vipin (one of the original RFC authors) but exacerbates this problem even more. (This control logic can support forked authentication chains for example.) I suspect that the most logical thing for Linux-PAM to do is to freeze the control path taken by a successful authentication and reuse it to perform all setcred calls. This will appear to behave as you want for your stated example. I do want to thank you for pointing this issue out. If you read to the end of URL above, you'll see that I appear to have dropped the setcred issue on the floor. I will attempt to resolve this in 0.75. Cheers Andrew
