[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Linux PAM fixes

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


> 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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []