[16951] in Kerberos_V5_Development
Re: Pluggable configuration design choices
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Jun 30 10:54:25 2011
MIME-Version: 1.0
In-Reply-To: <201106292201.p5TM1xoB024256@outgoing.mit.edu>
Date: Thu, 30 Jun 2011 09:53:43 -0500
Message-ID: <BANLkTin15JE-Jg0fLApY4dD4xjkQrUFKKw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: ghudson@mit.edu
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Wed, Jun 29, 2011 at 5:01 PM, <ghudson@mit.edu> wrote:> 1. Module selection and registration
I see the point about env vars given that this would allow replacementof krb5.conf.
My suggestion:
- Built-in configuration modules (i.e., compiled/linked in, or oneswhose shared object names are baked in) should have an initializationentry 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, ofcourse.
- The original krb5.conf backend should be able to specify additionalnon-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 whenbackends store typed values instead of plain strings. This alsoallows for some degree of type safety (since a get_int() could returnan error if the backend stored a value of a different type and it'snot 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 valuelists (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 thesame store as much as possible. I don't see any reason to haveseparate KDC configuration.
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
