Re: PAM_IGNORE (was Re: Why should setcred be called after session open?)

[Andrew Morgan <morgan transmeta com>]

Nicolas Williams wrote:
> 
> On Fri, May 25, 2001 at 09:54:11AM -0700, Andrew Morgan wrote:
> > Nicolas Williams wrote:
> >
> > There are some modules that cannot be used for authentication. Those
> > modules are supposed to be the ones that return PAM_IGNORE. pam_nologin
> > seems like a good example of this sort of thing.
> >
> > There is also a control token of 'optional' that permits an admin to
> > take an authenticating module (which returns pass/fail) and make it
> > irrelevant to whether the user gets authenticated or not.
> 
> Optional does not make the module irrelevant. If there's no
> required/requisite modules on the stack, then a single successful
> optional module suffices for the stack to succeed.

Yes, I guess that is fair. But, in the case where your module returns
PAM_SUCCESS or PAM_IGNORE (in lieu of PAM_PERM_DENIED), I believe the
'optional' control token is an admin way of obtaining the result you
want.

> > I believe Steve's concern is that, in Nicolas' scheme, a simple stack
> > like this:
> >
> >     auth  requisite pam_ruser_rhost_is_trusted
> >     auth  required  pam_krb5
> 
> What is pam_ruser_rhost_is_trusted? pam_rhosts? The idea is for it to be

I made it up. Its a module that doesn't care what PAM_USER is, just that
PAM_RUSER and PAM_RHOST are known to the system as requesting users that
are not denied access the service.

> sufficient. Making it requisite breaks the model.

What model? The modules are supposed to be generic authentication
machines, my concern is that by returning PAM_IGNORE, you are making an
assumption that krb5 is not the only authentication module in the stack
that requires that the PAM_USER exists.

> I think that Steve would agree to a different observation/proposal I
> made on the pam-krb5 list (he's not responded -- silence denotes consent
>:).
> 
> That is this:
> 
>  - it is not incorrect to call pam_krb5:account without calling
>    pam_krb5:auth, it's just meaningless, but nonetheless allowable
> 
>  - it IS incorrect to call pam_krb5:auth without also calling
>    pam_krb5:account, in the same pam handle
> 
>  - if desired we can add code to detect the second item above and
>    complain loudly.

What has this got to do with the PAM_IGNORE return code for
pam_sm_authenticate()?

> > Actually, I (should have - I can't remember if I actually did) said that
> > pam_krb5:pam_sm_setcred() gets called iff pam_krb5:pam_sm_authenticate()
> > was called. The return code of pam_krb5:pam_sm_authenticate() is not
> > important. If pam_authenticate() led to libpam invoking
> > pam_krb5:pam_sm_authenticate(), then pam_setcred() when called, will
> > definitely invoke pam_krb5:pam_sm_setcred(). [The path through the
> > 'auth' configuration for the setcred stack evaluation is defined by the
> > path taken during the authenticate stack evaluation.]
> 
> I thought that is what I said you said. Isn't it?

Your remark implied that PAM_IGNORE was in some way special. I wanted to
point out that if the pam_sm_authenticate() function returned anything
at all, it was guaranteed to cause pam_sm_setcred to be invoked.

> I take advantage of this behaviour in our pam_krb5. By default, if
> there's no keytab with which to validate a user's Kerberos credentials
> then pam_krb5:auth returns PAM_IGNORE (since it cannot really validate
> the password), but it does fetch Kerberos credentials, if possible, so
> that pam_krb5:setcred() can create a ccache. In such situations pam_krb5
> acts as a convinience kinit and cannot contribute to actually
> authenticating the user.

Since I'm not all that clueful about kerberos, I don't really understand
how one could not authenticate a user and yet successfully fetch a
user's credentials... Perhaps I should let Steve continue to speak for
himself...?

Cheers

Andrew