[1770] in Kerberos-V5-bugs
KDC locking bug: HIGH PRIORITY
daemon@ATHENA.MIT.EDU (Richard Basch)
Thu Jan 4 21:12:12 1996
Date: Thu, 4 Jan 1996 21:11:13 -0500
To: tytso@MIT.EDU, krb5-bugs@MIT.EDU
From: "Richard Basch" <basch@lehman.com>
I have noticed on my Solaris V5 KDC that there seems to be a database
locking problem. The following patch seems to correct the problem, but
I wanted someone else to check it over.
Scenario:
My V4 KDC does a kprop to my V5 KDC.
The V5 KDC takes the V4 dump file and generates a new database, using
kdb5_edit -s <script>
The script file reads as follows:
load_v4db -T -t -f /opt/krb5/data/v4.dump
As you can see, it says to generate a temporary database among other
things.
What I found was happening is that the KDC did not detect when the new
database had been moved into place. From the source, it looks like the
rename operation considered the source lock file to be the important one
to modify, but all the other services that are looking at the
destination database would be referring to the destination lock file.
The change here simply uses the target lock file during the db rename
operation, assuming that nobody else will be using the source (since it
will be gone momentarily). That way, a running KDC process will notice
the new db created by kdb5_edit.
I am sure the last part of the patch is correct, regarding the test for
a valid file descriptor and the inclusion of a missing unlock call.
-Richard
--- 1.1 1996/01/04 09:09:18
+++ src/lib/kdb/kdb_dbm.c 1996/01/04 09:09:32
@@ -886,11 +886,11 @@
context->db_context = (void *) NULL;
if (!(retval = k5dbm_init_context(context))) {
/*
- * Set the name of our temporary database context to the source
+ * Set the name of our temporary database context to the target
* database. We need to do this so that the database calls do the
* operations to the right lock file.
*/
- retval = krb5_dbm_db_set_name(context, from);
+ retval = krb5_dbm_db_set_name(context, to);
db_ctx = (krb5_db_context *) context->db_context;
if ((db_ctx->db_lf_name = gen_dbsuffix(db_ctx->db_name,
KDBM_LOCK_EXT(db_ctx)))) {
@@ -952,11 +952,14 @@
(fromdir && todir && (rename (fromdir, todir) == 0))) &&
((!frompag && !topag) ||
(frompag && topag && (rename (frompag, topag) == 0)))) {
- if (fromok && took)
- (void) rename(fromok, took);
- retval = 0;
- } else
- retval = errno;
+ /* We only need to unlink the source lock file */
+ (void) unlink(fromok);
+ retval = krb5_dbm_db_end_update(context);
+ } else {
+ (void) krb5_dbm_db_end_update(context);
+ retval = errno;
+ }
+
errout:
if (fromok)
@@ -973,16 +976,17 @@
free_dbsuffix (fromdir);
if (context->db_context) {
- if (db_ctx->db_lf_file) {
+ if (db_ctx->db_lf_file >= 0) {
krb5_dbm_db_unlock(context);
close(db_ctx->db_lf_file);
}
k5dbm_clear_context((krb5_db_context *) context->db_context);
free (context->db_context);
}
+
context->db_context = s_context;
+ (void) krb5_dbm_db_unlock(context); /* unlock saved context db */
- (void) krb5_dbm_db_unlock(context); /* unlock database */
return retval;
}
Richard Basch URL: http://web.mit.edu/basch/www/home.html
Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu
101 Hudson St., 33rd Floor Fax: +1-201-524-5828
Jersey City, NJ 07302-3988 Voice: +1-201-524-5049
