[1106] in Kerberos_V5_Development
Re: OV admin system integration plan
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Sun May 5 16:19:43 1996
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
Date: Sun, 05 May 1996 16:19:38 EDT
From: Marc Horowitz <marc@MIT.EDU>
First, a brief note on the session key PRNG (since that's what it is).
I have this feeling that we're all wandering around in the dark
hitting our heads on things. Oodles of stuff has been published on
good PRNG's by people who know more about the subject than we ever
will. Someone should pick up a copy of Schneier, read the section on
PRNG's, and pick a good one for our purposes.
Now, some comments on Barry's plan:
>> The primary requirement for a V4 compatibility server comes from MIT
>> itself; it is not critical for the public release to contain a
>> fully-functional V4 compat server. I propose the following actions:
Richard Basch claims to be using the v4kadmind. I'm curious why.
Perhaps it's because of the current pitiful state of the kadmind5 :-)
>> The KDC database is currently stored using DBM. The OV admin system
>> uses DB for its own databases, and DBM to access the KDC database.
"The kdb library currently uses the ndbm api. The OV admin system
code uses the berkeley db api for its own databases, and the kdb
library to access the KDC database." The rest of the paragraph
follows more clearly from this.
>> There are two obvious solutions to this problem. We can change
>> libkadmsrv to use a DB principal database instead of a DBM principal
>> database, or we can modify the DB library not to export DBM functions
>> so that the principal database remains in a DBM database. OV took the
>> latter approach, and it worked fine. The former would require
>> substantially more work. I propose that we modify the DB library not
>> to export DBM symbols, and keep the KDC using DBM for now.
What you mean (former solution) is that we can change libkdb5 to use
berkeley dbm instead of ndbm. There is a third solution: we can keep
the berkeley db library as-is, and the libkdb5 code will end up using
the ndbm-db compatibility interfaces, resulting in a db-format kdb on
disk. This database format will not be backward-compatible (and may
change in the future), but will work just fine. I have added my
thesis version of db 2.0 to my working copy of the tree, although
someone else will have to make it work within the mess we call a build
system.
>> \subsection{The KDC admin utilities}
There are currently a few programs which operate on the entire
database as a unit. They create, convert, dump, load, and destroy the
database. In krb4, there was a kdb_util program which performed all
these operations based on a command-line argument. I think that this
might be the right model for krb5, too, and we might merge the above
functionality into a single kdb5_util program.
>> o Admin API. Rename the functions from ovsec_kadm_* to kadm_*....
Convention in the tree would seem to indicate kadm5_* as a prefix, but
I'm interested in others' opinions. This is also true of the other
renamings you make.
Marc
