[141] in Kerberos_V5_Development
Re: libkdb.spec
qjb@ATHENA.MIT.EDU (qjb@ATHENA.MIT.EDU)
Mon Jan 22 14:24:58 1990
Comments on libkdb.spec:
krb5_db_get_principal:
The argument currently called "principal" should be called "principals"
according to our previously discussed naming conventions.
Likewise with free and put.
Some things start with krb5_db and others with krb5_kdb. They
should probably all start with krb5_db.
I think (strongly enough that I was going to write this for
version four) that it would be good for us to have a
delete_principal or perhaps a flag_delete_principal and an
expunge_db. Since dbm does have a delete function, so either of
these two options would be easy to implement.
Is it worth having a db_destroy function? Probably...
Should we have a db_get_name function, or are we going to say
that it is the responsibility of the programmer to keep track of
what the name is? I vote that we have a db_get_name function.
Shouldn't *age in db_get_age be a krb5_deltat instead of a
krb5_timestamp?
To be a bit picky, I'm not sure that I like the name
krb5_db_principal as a type name since, presumably, an object
of this type has not only a principal but all the other data
stored for a principal in the database. I would consider doing
a replace of principal to entry in most of the specs. Having a
krb5_db_entry would be consistent with the keytab interface as
well.
I see a problem here that we have discussed elsewhere as well.
There seems to be a concept of a default database. Where and
how is this stored? Does it support the multithreading we have
discussed? I'm tempted to say that we should have something of
type
krb5_database
that is analogous to krb5_keytab and krb5_ccache. krb5_db_init
could take a name and return a krb5_database object. It may not
be overkill to consider supporting multiple database
implementations (extending the analogy between krb5_database,
keytab, and ccache). Certainly dbm is the best thing we have to
use, but this may not be true for all systems. If we support
kerberos in a non-unix environment, will dbm even be available?
Since a kerberos database is a fairly simple thing, and since we
have some experience already with supporting multiple
implementations, perhaps the concept extends naturally to this
as well. If this is done, of course all of these routines would
have to take a krb5_database as a (the first?) parameter.
There is no mention anywhere in these specifications (that I
saw) of wild card support. We may want to consider this for
krb5_db_get_principal.
The db_iterate function brings up an interesting point that I
wish we had thought of earlier. This method of iterating seems
cleaner than the sequential get stuff used in the keytab and
ccache implementations. Would it be too ridiculous to consider
changing the interface of keytab and ccache to have a single
iterate routine that takes a function rather than three routines
(start, next, and end) and a cursor type?
Jay
