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 the URL above, you'll see that I appear to have dropped the setcred issue on the floor. I will attempt to redress this in 0.75.
Cheers
Andrew
This problem is more general than just the setcred issue.
The same problem exists for the pam_close_session() stack,
and the second of the two invocations of the pam_chauthtok()
stack.
I'm working on a general fix to libpam for this.
In addition to committing this change, there is an important need
to document the new behavior. It is significantly different to that
of previous releases, so there may well be backward compatibility
issues.... :^(
I've committed changes to implement this 'sane behavior', and added
some text to the documentation.
This change will appear in the 0.75 release.