[1285] in Kerberos_V5_Development
Re: changing libkdb database open/lock semantics
daemon@ATHENA.MIT.EDU (Christopher Provenzano)
Tue Jun 4 19:12:09 1996
Reply-To: proven@cygnus.com
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
In-Reply-To: Your message of "Mon, 03 Jun 1996 14:33:10 EDT."
<9606031833.AA09888@beeblebrox.MIT.EDU>
Date: Tue, 04 Jun 1996 12:54:19 -0400
From: Christopher Provenzano <proven@proven.org>
>
> 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
>
Yes, I am looking into this bug now and would prefer to find it than
change the implementation to something that is MUCH slower. I know that the
kdc closing and reopening the database is a safe operation (changing the
open to readonly would ensure that), and I know that the theory of
operation is sound.
I also know that this bug is fairly rare and that restarting the kdc
makes the problem go away. If you have a reproducable test case that
demonstartes the bug that would be more that helpful for me to find the
bug. My current guess is that it takes a db load to actually trigger the
bug and that the db load is replacing the existing lock file with another
thereby causeing the kdc to not see the updated lock.
CAP
