[17527] in Kerberos_V5_Development
Re: [RFC] kdb: store mkey list in context and permit NULL mkey for
daemon@ATHENA.MIT.EDU (Will Fiveash)
Mon Feb 27 20:22:39 2012
Date: Mon, 27 Feb 2012 19:22:30 -0600
From: Will Fiveash <will.fiveash@oracle.com>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <20120228012230.GC21501@oracle.com>
Mail-Followup-To: Greg Hudson <ghudson@mit.edu>, krbdev@mit.edu
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F45BC10.9050403@mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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/>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
