[1275] in Kerberos_V5_Development
changing libkdb database open/lock semantics
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Mon Jun 3 14:33:32 1996
Date: Mon, 3 Jun 96 14:33:10 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krbdev@MIT.EDU
I spent all afternoon on Friday trying to track down a bug that caused
the KDC to report principals as not existing that did exist accord to
kdb5_edit; the bug was preventing the kadm5 api unit tests from
running. I never really found it, but while looking I came to the
conclusion that the way libkdb handles database locking is unsafe; I
would therefore like to change it.
Currently, krb5_db_init opens the database and opens the lock file.
Whenever the database is modified, krb5_db_set_age() is called to
update the mod time on the lock file. krb5_db_lock acquires a lock
and checks the mod time on the lock file; if it has changed since last
read, the database is closed and reopened. Also, any function that
writes to the database (put_principal and delete_principal) closes and
reopens the database after each write. krb5_db_fini() performs the
final close.
This approach concerns me because it allows a process to close() a
database that has been modified out from under it (it also concerns me
because it doesn't work). Perhaps this is a safe operation, but that
is far from clear and may depend on the database layer. It may also
depend on the mode in which the db was opened---and libkdb currently
always opens read-write (perhaps that is the real source of the bug).
I propose a different scheme in which the database always remains
closed except inside a lock/unlock bracket. krb5_db_init just
allocates the structure and opens the lock file. krb5_db_lock
acquires a lock and then opens the database; krb5_db_unlock closes the
database and unlocks the file. As a side effect, put_principal and
delete_principal no longer have to deal with syncing the database
after each write, since it will automatically be closed. This is how
the admin library maintains its own database. I've already made the
changes to my local copy of kdb_dbm.c, they are not extensive, and
they make the code shorter and simpler overall. With this change, the
kadm5 api tests no longer cause the KDC to break.
This scheme does have the disadvantage that the KDC opens and closes
the database for every transaction which is clearly ineffecient, but
I'd say that disadvantage is outweighed by the advantage that code
works at all. :-)
Comments?
Barry
