Draft kadmind plugin API (2007-04-27)

[Russ Allbery]

Sam Hartman <hartmans at mit.edu> writes:

> My preference is that you work with Ken to find a solution to [1].  I
> care more about the usability of the API and the ease withwhich we can
> add new plugin interfaces than I do about sharp abstractions between
> k5support and libkrb5.  I care a lot about removing duplication of code.
> ,Reecoding loops to deal with plugins in libkadm5srv, libkrb5, the kdc,
> etc, is undesirable and I believe this is already going on.  Minimizing
> the complexity of those loops by moving code into anabstraction is good.
> I don't think there are parts of our code that could not somehow get a
> krb5_context if they needed one.  Having libk5support link against
> libkrb5 is potentially problematic.

Works for me.  Ken, any thoughts on where to start here?  Anything I
should look at to copy or evaluate?  It's pretty easy, looking at the
support APIs, to do the bit of reading every plugin in a directory, but
I'm a bit at a loss as to how to integrate with the profile library and
read preference information from there.

> [2] Passwords in k5crypto are treated as krb5_data; the string2key
> function certainly can deal with nulls.  So, at the kerberos level at
> least passwords are not C strings.  If you do treat passwords as
> length+data please use krb5_data.  Also, if you do this in your
> implementation please do null terminate.

Sounds like using krb5_data is a good idea.  What should I use as the
value of the magic field, or does it not matter?

I think I used null-terminated strings to start with because
krb5_set_password_using_ccache uses a null-terminated string, and that's
the main thing I was calling under the hood to push passwords to AD.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>