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).
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.
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.
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.)
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.]
> 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
#
# you only get here if you are 'me', 'you', 'him', or 'her'.
#
auth requisite pam_foobar.so
The same rule applies for the effective 'cred' stack in this case. It
either becomes:
cred optional pam_user_in_arglist.so me you him her
cred required pam_unix.so
cred optional pam_permit.so
or
cred required pam_user_in_arglist.so me you him her
cred required pam_foobar.so
depending on which authentication fork we ended up taking to
authenticate the user.
Cheers
Andrew
