Nicolas Williams wrote:
> > Exactly, and this is /wrong/. PAM_IGNORE means "I have nothing useful to
> > contribute". Returning an error when we don't know who the principal is is
> > not only useful, it's imperative in the case of configs such as the above. If
> > we want admins to be able to turn this behavior off with a module option,
> > that's fine, but returning PAM_IGNORE here is not sane default behavior.
>
> I disagree. It's always appropriate to return PAM_IGNORE because it
> cannot contribute to success of the stack.
>
> > If I list two authorization modules as 'requisite' or 'required' in my PAM
> > config, then by God, I don't want that user to be allowed access to the
> > service unless both of those modules are *sure* that he should be.
>
> Well, this is PAM. It's how it works. Perhaps Andrew Morgan can settle
> this.
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.
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
will succeed - even if the user is unknown to kerberos. This sort of
thing looks very wrong to me. I believe that pam_krb5 gets called as an
auth module it should pass/fail within its own sphere of knowledge.
PAM_IGNORE, might be a legitimate alternative to PAM_USER_UNKNOWN only
if forced by some pam_krb5 module argument - which implies that the
admin has read the documentation and knows what they are doing.
> > > > Under Solaris w/ rlogin, is pam_krb5's pam_sm_setcred() being called even
> > > > though its pam_sm_authenticate() function was never called? Some of your
> >
> > > Yes. Andrew Morgan says this would not be the case with Linux-PAM,
> > > ALTHOUGH, if PAM_KRB5:pam_sm_authenticate() is called and returns
> > > PAM)IGNORE, then PAM_KRB5:pam_sm_setcred() WOULD be called in the
> > > Linux-PAM case.
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.]
Cheers
Andrew
