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. > 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 sufficient. Making it requisite breaks the model. 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. > 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. Right. > > > > > 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.] I thought that is what I said you said. Isn't it? 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. > Cheers > > Andrew Nico --
