Pluggable configuration design choices

Nico Williams nico at cryptonector.com
Thu Jun 30 10:53:43 EDT 2011


On Wed, Jun 29, 2011 at 5:01 PM,  <ghudson at mit.edu> wrote:
> 1. Module selection and registration

I see the point about env vars given that this would allow replacement
of krb5.conf.

My suggestion:

 - Built-in configuration modules (i.e., compiled/linked in, or ones
whose shared object names are baked in) should have an initialization
entry point whose job is to find their configuration data's location.

   This way you can leave any env var handling to those modules.
You'll need a "secure" flag argument to this init entry point, of
course.

 - The original krb5.conf backend should be able to specify additional
non-built-in modules and ancilliary information for them.

> 2. Plugin interface
>
> Based on past input, I'm assuming that we will need read and write
> methods.  The core krb5 code doesn't need to write to configuration
> sources, but the profile API allows applications to do so.  I'll just
> talk about the read methods here, and assume that the write methods
> mirror them (plus a "flush" method).  Of course write methods will be
> optional to implement.
>
> A configuration plugin will map keys to values.  Keys will probably be
> represented as a null-terminated array of C strings
> (e.g. {"libdefaults", "allow-weak-crypto", NULL}).  From there, some
> options are:

Sure.

> * Minimal: Just have a single "get" method for mapping keys to a list
>  of strings.
>
> [...]
> * Typed with fallback: if, say, get_int isn't implemented by the
>  plugin, call the basic get and convert the first string value to an
>  integer.
>
> [...]

I say: go for typed with fallback.  This allows for efficiency when
backends store typed values instead of plain strings.  This also
allows for some degree of type safety (since a get_int() could return
an error if the backend stored a value of a different type and it's
not willing to do type conversion even when it'd be feasible).

> Do we need iteration methods?  I don't think we do.

Just a "get all values" method.  Presumably there won't be huge value
lists (yeah, I noticed Sam's point about capaths).

> 3. KDC configuration
>
> We have a special class of configuration consumers for programs which
> run on the KDC (krb5kdc, kadmind, kdb5_util, etc.).  Right now they
> merge a second kdc.conf file into the profile.  We'll need some
> analagous behavior when a configuration plugin is in use.  An obvious
> choice is a boolen argument to the plugin initializer saying whether
> the consumer is a KDC-type program.

All non-library-but-Kerberos-related configuration should be in the
same store as much as possible.  I don't see any reason to have
separate KDC configuration.

Nico
--




More information about the krbdev mailing list