Review of Projects/Kadmin hook interface

[Russ Allbery]

Sam Hartman <hartmans at MIT.EDU> writes:

> I've started a review of
> http://k5wiki.kerberos.org/wiki/Projects/Kadmin_hook_interface; send
> comments by 2010-10-06.

> Here is the brief overview; see the wiki for a proposed header file.
>    The Kadm5 hook interface provides a plugin interface for plugins to be
>    aware of administrative operations for kadm5 principals. Plugins track
>    the following administrative operations:
>      * Principal creation
>      * Change password
>      * Principal modification

>    The plugins are called twice: once in a precommit phase before the
>    operation takes place and if no plugins fail and the database is
>    updated, once in a postcommit operation. This interface is based on a
>    proposed patch to Heimdal by Russ Allbery for the [8]krb5-sync plugin.
>    Russ indicated that Heimdal is likely to adopt an approach based on
>    stackable database plugins rather than his approach. That's probably
>    undesirable for MIT because the kadm5 API is more stable than the KDB
>    API and because this interface is easier for plugin authors than
>    writing a KDB module. This interface has the following changes from
>    Russ's interface:
>     1. Opaque struct rather than void * for the module context
>     2. Include key-salt tuples for create/chpass
>     3. Add a remove entry point
>     4. Remove name and vendor entries to be consistent with other plugin
>        framework uses

I would also document how this module is called if the key is being
randomized (if at all).  It would probably be best to add a separate
interface that gets all of the keys, although in my specific use case
(propagation to Active Directory), there isn't anything one can really do
about a randomized key other than randomizing the password in Active
Directory (to something unrelated to the new randomized key).

For a complete interface, you probably also want to add rename and
chpass_with_key.  I didn't have those in my Heimdal hooks for the same
reason I didn't have remove: I didn't need them for my immediate problem
and hadn't had time to work on the broader issue.

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