[16380] in Kerberos_V5_Development
Re: Review of Projects/Kadmin hook interface
daemon@ATHENA.MIT.EDU (Russ Allbery)
Mon Sep 27 14:32:34 2010
From: Russ Allbery <rra@stanford.edu>
To: Sam Hartman <hartmans@mit.edu>
In-Reply-To: <tslpqvzvzmh.fsf@live.suchdamage.org> (Sam Hartman's message of
"Mon, 27 Sep 2010 13:56:54 -0400")
Date: Mon, 27 Sep 2010 11:32:30 -0700
Message-ID: <871v8fvxz5.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Cc: lha@h5l.org, krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Sam Hartman <hartmans@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@stanford.edu) <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
