[RFC] kdb: store mkey list in context and permit NULL mkey for kdb_dbe_decrypt_key_data

Greg Hudson ghudson at MIT.EDU
Wed Feb 22 23:09:52 EST 2012

On 02/22/2012 07:03 PM, Will Fiveash wrote:
> krb5_db_fetch_mkey_list() would
> be modified to just update that field and not return that master_keylist
> in an output parameter as it does now.  It would free the existing mkey
> list if v->fetch_master_key_list() succeeded and set
> kcontext->dal_handle->master_keylist to the new mkey list.  It would not
> set the context->dal_handle->free_keylist as I don't think this is
> needed.  kdb_free_lib_handle() would free dal_handle->master_keylist if
> it was not NULL.  Is this a reasonable modification?

I'm all for simplifying the interface if possible, but I think there are
some uses of the master key list in kdb5_util which aren't as easily
removed, including:

* kdb5_util stash needs a way to write out the master key list to a
stash file.  This could probably be handled by making
krb5_db_store_master_key_list() use the dal_handle list.

* kdb5_util ark (why do we even have this?) needs to encrypt the new key
in the same master key as the old one.  Probably krb5_dbe_ark() could be
changed to use the dal_handle master key list.

* kdb5_util add_mkey needs to iterate over the master key list to create

* kdb5_util use_mkey needs to iterate over the master key list to verify
that the kvno is valid.

* kdb5_util list_mkeys needs to iterate over the master key list to
display entries.

More information about the krbdev mailing list