On Fri, Nov 06, 2009 at 05:37:12PM -0600, Nicolas Williams wrote: > 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.
My concern with this is that I'm proposing support of two instances of pam_krb5 in a auth stack and some of these module options may only apply to one instance or the other. For example, if we end up supporting a do_pkinit module option, what sort of logic would pam_krb5 need to understand whether that option, as set in a pam_krb5 stanza in krb5.conf, applies to the current instance? I think instance specific options should only be in pam.conf to avoid this ambiguity. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA
