[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:

I added:

+krb5_keylist_node *
+krb5_dbe_mkey_list(krb5_context kcontext)
+{
+    return kcontext->dal_handle->master_keylist;
+}

to usr/src/lib/krb5/kdb/kdb5.c as an accessor function for things that
need to go through the master_keylist but find the dal_handle struct to
be opaque.  Here is that list (this is Solaris code):

Functions calling this function: krb5_dbe_mkey_list

  File                           Function                     Line
1 krb5/kadmin/dbutil/kdb5_mkey.c add_new_mkey                   86 krb5_keylist_node *master_keylist =
                                                                   krb5_dbe_mkey_list(context);
2 krb5/kadmin/dbutil/kdb5_mkey.c kdb5_use_mkey                 465 krb5_keylist_node *master_keylist =
                                                                   krb5_dbe_mkey_list(util_context);
3 krb5/kadmin/dbutil/kdb5_mkey.c kdb5_list_mkeys               736 krb5_keylist_node *master_keylist =
                                                                   krb5_dbe_mkey_list(util_context);
4 krb5/kadmin/dbutil/kdb5_mkey.c kdb5_update_princ_encryption 1144 krb5_keylist_node *master_keylist =
                                                                   krb5_dbe_mkey_list(util_context);
5 krb5/kadmin/dbutil/kdb5_mkey.c kdb5_purge_mkeys             1368 krb5_keylist_node *master_keylist =
                                                                   krb5_dbe_mkey_list(util_context);

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

That's a good question.  Checking the ark command out it just adds a set
of random keys to a princ.  When I run:

svn blame src/kadmin/dbutil/kdb5_util.c

I see:

13028   epeisach static void
 11001       marc add_random_key(argc, argv)
 11001       marc     int argc;
 11001       marc     char **argv;
 11001       marc {
 11001       marc     krb5_error_code ret;
 11001       marc     krb5_principal princ;

This is:

r11001 | marc | 1998-10-29 20:56:35 -0600 (Thu, 29 Oct 1998) | 2 lines

pull up 3des implementation from the marc-3des branch

I'm wondering if anyone actually uses this?  Googling didn't bring up
anything interesting.

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

I'm still testing my changes but in general things look good and there
are no mem leaks.

-- 
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/>