Draft kadmind plugin API (2007-04-27)
rra at stanford.edu
Thu May 3 23:29:14 EDT 2007
Sam Hartman <hartmans at mit.edu> writes:
> My preference is that you work with Ken to find a solution to . 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.
>  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/>
More information about the krbdev