[1369] in Kerberos_V5_Development
kdb5_destroy fails silently (not good)
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Tue Jul 2 16:00:26 1996
Date: Tue, 2 Jul 1996 15:59:42 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krbdev@MIT.EDU
In-Reply-To: [1350]
Date: Tue, 25 Jun 96 16:41:59 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
Remember how I argued that we should not support multiple database
backends, etc., because it introduced too much complexity that was
sure to bite us? Well...
kdb5_edit's load_db command in krb5 beta 6 cannot work if libkdb.a is
compiled to use the ndbm interface but linked with BSD DB...
This problem affects kdb5_destroy as well. krb5_dbm_db_destroy()
attempts to destroy files having the data, index, and lock extension
of the database name. If you are using ndbm interface of BSD DB,
files with those extensions do not exist. The problem is even worse,
though, because destroy_file_suffix, which krb5_dbm_db_destroy uses to
destroy to files, does not consider ENOENT an error; it explicitly
catches that error code and returns 0 instead of failure. Probably
the reasoning was that if you are trying to destroy a file and it
does not exist, then you succeeded, but in this case it can lead an
administrator to believe falsely that the data has been destroyed.
I am going to rewrite krb5_dbm_db_destroy in two ways:
(1) It will consider ENOENT an error, so that destroying a
non-existent database will generate an error message. This seems far
preferrable to silently failing in the case above.
(2) Hard-code knowledge about the BSD DB file extensions, as I did
with krb5_dbm_db_rename, so that the code works in all cases.
Barry
