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

[Will Fiveash]

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
> krb5_mkey_aux_nodes.
> 
> * 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.

-- 
Will Fiveash
Oracle Solaris Software Engineer
http://opensolaris.org/os/project/kerberos/
Sent using mutt, a sweet, text based e-mail app <http://www.mutt.org/>