On Fri, Nov 06, 2009 at 05:06:27PM -0600, Will Fiveash wrote: > On Thu, Nov 05, 2009 at 02:18:33PM -0800, Henry B. Hotz wrote: > > Couple of points: > > > > While I don't specifically advocate it, I note that Russ' pam_krb5 and the > > RedHat pam_krb5 both use configuration info in krb5.conf. I personally > > would think that's simpler, but probably less "pam-like". > > Yes, I'm aware of that but Solaris pam_krb has not supported that up to > this point while it has supported pam.conf stanza line arguments which > is why I was leaning that direction for a password fallback option.
I'm a fan of having module options for important behaviors because I like to know what I'm getting just by looking at pam.conf. Not all possible module options are of that kind. For example, options about what krb5 ccache type to use, etcetera, are irrelevant to how a PAM stack will be evaluated. Module options that can cause a module to return PAM_IGNORE are the kind of options that I'm talking about, but not *all* such options (for example, an "ignore_user_unknown" option would be OK in krb5.conf instead of as a module option). But even so, I think we should provide krb5.conf [pam] section equivalents for any module options. Nico --
