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
