[1181] in Kerberos_V5_Development
krb5_db_entry and kadm5 info
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Wed May 15 15:56:23 1996
Date: Wed, 15 May 1996 15:56:08 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krbdev@MIT.EDU
The OV admin system associates some information with principals that
is not stored in the krb5_db_entry (basically, the principal's policy
and password history). When you call ovsec_kadm_get_principal, you
get back a data type called ovsec_kadm_principal_ent_t which contains
a union of the data from the krb5_db_entry and from the admin
database; this mostly-redundant structure was necessary because the
krb5_db_entry did not have space for the admin fields the OV system
needed to return.
In the current integration so far, the data that used to be stored in
a separate admin database is now stored in a tl_data structure. Thus,
in principle, the redundant structure ovsec_kadm_principal_ent_t is no
longer necessary. kadm5_get_principal can just return the
krb5_db_entry for the requested principal.
This is a really ugly solution, however, because of the use of
tl_data. If you want to access admin info (say, the policy name), you
have to (1) call kadm5_get_principal and (2) call
krb5_dbe_lookup_tl_data. Simiarly, to update data, you can't just
call kadm5_put_principal, you first have to call
krb5_dbe_upate_tl_data too. It also requires that we either define a
searpate tl_data type for each piece of admin data or (as it is now)
require a program to deal with *all* the admin data every time it
wants to touch any of it. Blech.
The basic problem here is that the entire tl_data setup is difficult
to work with. I think that all the data contained in the
krb5_db_entry should be directly accessible rather than having some of
it buried in a linked list. Since the admin system requires new
information to be added to entries, we should just define a new
database entry version. There does not seem to be an explicit
database entry versioning system in place, though; however, we are
probably going to force users to do a dump/load cycle with krb5 1.0
anyway, so this is a good time to introduce one.
In short, I'd like to remove the tl_data list from krb5_db_entry, and
add the following fields:
int version; /* database entry vno */
krb5_timestamp last_pwd_change;
krb5_timestamp mod_date;
krb5_principal mod_princ;
char * policy; /* admin policy name */
krb5_key_data *hist_data; /* password history */
Comments? Why was the tl_data list created in the first place? Does
anyone even follow what I'm talking about? :-)
Barry
