Re: Why should setcred be called after session open?

[Andrew Morgan <morgan transmeta com>]

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