On Mon, Nov 09, 2009 at 12:46:11PM -0600, Will Fiveash wrote:
> > 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?
It's clear that a module option that can be on for some services, and
off for some others (or where the module can be stacked twice for one
service but with different choices for that option) has to be a module
option that appears in pam.conf and which can override the same module
option if it can be specified elsewhere (such as in krb5.conf).
It's not clear that such a module option must only be the kind that
appears in pam.conf and not elsewhere.
> I think instance specific options should only be in pam.conf to avoid
> this ambiguity.
As I've said before, some options clearly are uninteresting for someone
reading pam.conf, while some are very interesting. IMO that's the
distinction that matters here.
I don't think we need do_pkinit because position relative to
pam_authtok_get is good enough [for me], but this is something w.r.t.
reasonable people can disagree -- I don't feel strongly about that.
IMO it'd be reasonable to:
- have default module behavior as specified in the case materials so
far (i.e., try PKINIT if PAM_AUTHTOK is not set, dual stacking, ...)
- have a [pam] stanza in krb5.conf where the module's default can be
set
- have a module option to force the use of PKINIT regardless of whether
PAM_AUTHTOK is set and regardless of what is specified in krb5.conf
- have a module option to force the use of password-based pre-auth,
regardless of what is specified in krb5.conf
Nico
--
