Configuration information from plugins

[Ken Hornstein]

Recently I've been using the various MIT Kerberos plugin APIs to replace
a lot of the custom patches we've accumulated over the years, and
overall it's been a wonderful experience and has made my life a lot
easier.  So, huge positive there!

One MINOR downside to the plugin APIs in general is that I find myself
re-implementing the same code in each plugin, specifically the code to
look up profile values from the configuration file.  It turns out that
it's inevitable that I need to do some kind of runtime configuration in
pretty much every plugin I've writen; at a minimum I need a flag that
turns on debugging output (because something is always going to go wrong
at some point), and all of the functionality I need has some kind of
configuration setting that it makes sense to configure at runtime.

I realize that you can access everything via the public APIs, but
what I end up re-implementing seems to be the middle part of the profile
routines.  Specifically:

- The routines to parse a boolean value.  It looks like this is centralized
  into krb5int_libdefaults_boolean(), but that's an internal function.
  I also know about profile_get_boolean() which IS public, but that
  doesn't quite work; you can't tell the difference between "this
  entry doesn't exist so we gave you the default value" and "this
  value DOES exist, but it's the same as the default value", so you
  can't look for something under [realms] and then something under
  [kdcdefaults].

- The routines to search for a string under the [realms] stanza for
  a specific realm and then under a generic stanza (like libdefaults
  or kdcdefaults).

- The routine (for KDC plugins) to generate a list of configured realms
  so you can have per-realm configuration settings (this lets you fetch
  the per-realm configuration at initialization time).  The interface
  here isn't ideal since you don't always know which realm you're
  processing in a KDC plugin (but you do for preauth plugins).

I know about the appdefaults interface, but my feeling was that is
for "applications" and plugins aren't really applications.  All of
the included plugins use krb5.conf/kdc.conf and [libdefaults] or
[kdcdefaults] and that makes sense to me since they extend core
functionality.  That begs the question of where third-party plugin
configuration SHOULD go and what the thinking is here; if the answer is,
"Huh, we didn't really think much about that", then that's fine, but
maybe it's time to think about it.

I guess right now I don't have any specific suggestions; I wanted to
know what the thinking is here.  How should plugins do configuration?
If the answer is using krb5.conf is fine, then where should that
configuration go in the configuration hierarchy?  Should a few
more convenience functions be exposed from the library?  Should there
be a consistent way of determining the current realm that is in
use?  (I think that is only an issue for KDC plugins).

--Ken