[1227] in Kerberos_V5_Development
tl_data, e_data, and kadm5
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Thu May 23 12:24:00 1996
Date: Thu, 23 May 96 12:24:10 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krbdev@MIT.EDU
As I specified in the kadm5 integration plan I circulated several
weeks ago, I have been working towards a goal of having essentially
all programs that use the Kerberos database do so through the kadm5
api. So far, everything is going well. I have just started adding
kdb5_edit's load/dump capability to kadmin, however, and I am
beginning to wonder whether this isn't an exception.
The issue involves tl_data and e_data. These are both mechanisms for
adding "additional information" to the database without having to
change code that does not understand/use the new information. Should
the kadm5 interface provide tl_data and e_data? If not, then it
really cannot implement dump/load, since the cycle would lose all the
tl_data and e_data that the kadm5 system did not explicitly know
about.
It seems sensible for kadm5 to export the tl_data list. A program
that would want to store tl_data using the libkdb interface would
presumably still want to do so with the kadm5 interface; in fact,
doing so with the kadm5 interface could be a big improvement since
then the program could run on a remote machine securely. I imagine
there could be all kinds of kadm5 clients interested in storing their
own per-principal tagged data.
It seems much less sensible for kadm5 to export the e_data (and
e_length) fields. These two fields are very specific to the
libkdb-on-db(m) implementation. The kadm5 interface is supposed to be
independent of the database layer; that is why it has its own
principal type instead of using krb5_db_entry directly.
Having now written this message, I think the right solution is for the
kadm5 system to define its own tl_data type, KRB5_TL_E_DATA, that it
uses to export/import the e_data field of a db_entry. The new tl type
will only be present when the underlying database is dbm and has
e_data, and this will allow the kadmin client to dump/load in existing
formats. In the new format (which has to be defined anyway to include
admin policy information), the e_data fields will not be included
separately but just as another entry in the tl_data list; the admin
import routines will then parse them into e_data.
So I guess this message has turned from a question into a proposal.
I'll implement what I've described above unless someone complains
otherwise. If you have no clue what I'm rambling about, just ignore
me and assume I'm right. :-)
Barry
