On Fri, 25 May 2001, Andrew Morgan wrote: > > > 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. I think all the salient arguments have also been made on the pam-krb5 list now, but this does nicely summarize the issue. I greatly prefer that the default behavior inconvenience some admins by denying access to some of their users who should be allowed, than that it inconvenience others by allowing access to users who should be denied. That such a situation depends on the presence of buggy applications, and that the behavior of pam_krb5 is documented, will be of little comfort to the admin who finds his system security compromised. Steve Langasek postmodern programmer
