[RFC] kdb: store mkey list in context and permit NULL mkey for kdb_dbe_decrypt_key_data
will.fiveash at oracle.com
Thu Feb 23 13:28:11 EST 2012
On Wed, Feb 22, 2012 at 11:09:52PM -0500, Greg Hudson wrote:
> 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.
Thanks for thinking about this. I will look at all the uses of the
master key list and see if the dal_handle can be accessed for the
functions you mention above. If that is possible I will go ahead and
make the mods and present a patch in this thread.
Oracle Solaris Software Engineer
Sent using mutt, a sweet, text based e-mail app <http://www.mutt.org/>
More information about the krbdev