On Fri, May 25, 2001 at 11:56:09AM -0700, Andrew Morgan wrote: > Nicolas Williams wrote: > > > > On Fri, May 25, 2001 at 09:54:11AM -0700, Andrew Morgan wrote: > > > Nicolas Williams wrote: > > 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 suppuse an "insufficient" specifier might be useful... > > 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. The model we were discussing, whereby successful pam_rhosts should suffice, but when it fails then pam_krb5 authentication should be required. The issue is that in such cases, though pam_krb5's pam_sm_authenticate() is NOT called, it's pam_sm_acct_mgmt() would still be called: auth sufficient pam_rhosts auth required pam_krb5 account required pam_krb5 ... > > 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()? Nothing -- it's to do with pam_sm_acct_mgmt() returning PAM_IGNORE. See above. My contention is that pam_krb5:pam_sm_acct_mgmt() should return PAM_IGNORE if pam_krb5:pam_sm_authenticate() is not called (see above for an example). > > 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. Ok. > > 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...? Because, with Kerberos you authenticate to the KDC to get your credentials, but the credentials aren't signed with a KDC public key (there's no such thing currently) so authenticating to the KDC does not imply authenticating to your local host! To authenticate to the local host you must use your credentials to get a service ticket that your local host can validate, and that requires that your host have a Kerberos service account. It's valid to run a Kerberos realm where some hosts have no such account, and thus have no way to use Kerberos to validate passwords and authenticate users. Yes, it's somewhat odd. But it works, and well. Similarly, expired passwords can't be validated with Kerberos until they are changed -- this is because expired password can only be used to get service tickets to the password changing service, and such tickets cannot be used to authenticate to the local host. This is why our pam_krb5's (devl branch) pam_sm_chauthtok() calls its pam_sm_authenticate() and pam_sm_acct_mgmt() after changing an expired password! Just as there's an error, PAM_NEW_AUTHTOK_REQD, that pam_acct_mgmt() can return to indicate that the app should call pam_chauthtok(), methinks there could be an error which pam_chauthtok() can return to indicate that the user should be re-authenticated/re-authorized. But, as you can see, one can work around the absence of such an error. > Cheers > > Andrew Nico --
