Configuration information from plugins
kenh at cmf.nrl.navy.mil
Wed Nov 18 12:32:01 EST 2020
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
- 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
- The routines to search for a string under the [realms] stanza for
a specific realm and then under a generic stanza (like libdefaults
- 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).
More information about the krbdev