[1188] in Kerberos_V5_Development
Re: krb5_db_entry and kadm5 info
daemon@ATHENA.MIT.EDU (Christopher Provenzano)
Wed May 15 22:20:41 1996
Reply-To: proven@cygnus.com
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
In-Reply-To: Your message of "Wed, 15 May 1996 15:56:08 EDT."
<9605151956.AA28601@starkiller.MIT.EDU>
Date: Wed, 15 May 1996 22:17:51 -0400
From: Christopher Provenzano <proven@proven.org>
>
> 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? :-)
I object VERY strongly to this addition for a number of reasons.
1. The new information you are adding (policy and history) really
does not belong in the kdb. A separate database really is the correct
place for it.
2. The kdc has no need to look at any of those fields so why should
it go through the trouble of decoding them.
3. The point of the tl_data structures is to create an extensible database.
New fields can be easily added without requiring dump/reloads. Not only is
the database backwards compatible. It is also forward compatible.
4. Not all principals will need to store this data. (Especially the
history) so why waste the space.
5. I disagree with your statement that the tl_data setup is difficult
to work with. The two step process to get the info is not that much of
a problem and is really correct because the information you are accessing
is secondary in importance to what is stored in the base structure.
6. If some other company decides to make their own admin server
that uses different fields then the above you are requiring them
to either rewrite the databsae or to waste a significant amount of space
per principal on datafields that they don't care about.
The point of the base structure was that it is the least amount of data
necessary for the kdc and that everything else should go in tl_data
strutures because they won't be accessed as often and so the additional
work to decode them won't matter.
CAP
