On Tue, May 15, 2001 at 09:59:23AM -0700, Andrew Morgan wrote:
> Regarding the whole pam_setcred() thing. Its pretty much a disaster: ill
> defined. I think we need some sort of event-driven support to properly
> make use of such stuff as pam_setcred(pamh, PAM_REINITIALIZE_CRED).
Heh.
> Nicolas Williams wrote:
> > Remember, a module's pam_sm_setcred() should always be called
> > regardless of wether that module's pam_sm_authenticate() was called, so
> > long as the app calls pam_setcred().
>
> 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.
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.
Consider PAM_KRB5 and PAM_AFS. If PAM_KRB5 is sufficient for
authentication then a ccache will be available for
PAM_AFS:pam_sm_setcred() to reference, but PAM_AFS must come after
PAM_KRB5 in the stack, so given what you say PAM_AFS:pam_sm_setcred()
would not be called.
I think more thought needs to go into this... It's all, umm, rather icky.
> After some buggy behavior with earlier Linux-PAM versions, when
> evaluating the pam_setcred() stack, now invokes all of the modules that
> pam_authenticate() invoked. Notably,
>
> auth sufficient pam_foo1.so
> auth optional pam_foo2.so
> auth required pam_foo3.so
> auth sufficient pam_foo4.so
> auth requisite pam_foo5.so
>
> If pam_foo1.so satisfied the pam_authenticate() call, then pam_setcred()
> will only invoke pam_foo1.so. Similarly, if pam_authenticate() finds
> pam_foo1.so fails, but pam_foo3.so and pam_foo4.so return success,
> pam_setcred() will invoke pam_foo{1,2,3,4}.so, but not pam_foo5.so.
See above. I think pam_foo[2345]:pam_sm_setcred() might be interested in
knowing that the PAM_USER has been authenticated successfully without
pam_foo[2345]:pam_sm_authenticate() being called... Am I'm missing
something that would make such modules break?
> Note, this rule has also been extended to cover the 'password' and
> 'session' stacks too. (Eg, make sure we match the closes to the opens.)
Why password? I can understand session...
> In line with this all pam_sm_setcred() functions are now expected to
> return something sane (like PAM_SUCCESS, or PAM_IGNORE, or
> PAM_PERM_DENIED). Notably, the subset of the 'auth' stack that becomes
> the 'cred' stack is effectively one of the following (depending on how
> pam_authenticate() returned success):
>
> cred optional pam_foo1.so
>
> or,
>
> cred optional pam_foo1.so
> cred optional pam_foo2.so
> cred required pam_foo3.so
> cred optional pam_foo4.so
>
> or,
>
> cred optional pam_foo1.so
> cred optional pam_foo2.so
> cred required pam_foo3.so
> cred optional pam_foo4.so
> cred required pam_foo5.so
>
> [Having worked through this example, I'm a little concerned about the
> 'optional' status of the last entry in the first two of these stacks. In
> the first case it is not actually a problem, but in the middle example
> it seems to convey exactly the opposite sense from what I had intended..
> Mmm. Must think some more. I'll file a bug report from this email.]
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...
> > This is why I argue for a boolean expression system for specifying PAM
> > stacks.
>
> I didn't quite follow your explanation before about this. But, it is
> already possible, with Linux-PAM, to specify effective
> forked-authentication chains:
>
> 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.,
where is the fork? Is the success=2 a "skip 2 if success" directive?? If
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...
[...]
> Cheers
>
> Andrew
Cheers,
Nico
--
