Don't reopen the KDB in update_princ_encryption

kdb5_util update_princ_encryption iterates over the KDB and writes
modified entries.  With the DB2 back end, the first write operation
has to upgrade the lock and reopen the DB, which resets the cursor
state.  Take out an explicit write lock before iterating to avoid this
step.

ticket: 7684 (new)

diff --git a/src/kadmin/dbutil/kdb5_mkey.c b/src/kadmin/dbutil/kdb5_mkey.c
index 4edacb62483106af9bca72ea761a63a3e35180a4..0fbbb78ed32061aeca33432a1c4d8a65e24f5098 100644 (file)
--- a/src/kadmin/dbutil/kdb5_mkey.c
+++ b/src/kadmin/dbutil/kdb5_mkey.c
@@ -1050,6 +1050,16 @@ kdb5_update_princ_encryption(int argc, char *argv[])
         }
     }
 
+    if (!data.dry_run) {
+        /* Grab a write lock so we don't have to upgrade to a write lock and
+         * reopen the DB while iterating. */
+        retval = krb5_db_lock(util_context, KRB5_DB_LOCKMODE_EXCLUSIVE);
+        if (retval != 0 && retval != KRB5_PLUGIN_OP_NOTSUPP) {
+            com_err(progname, retval, _("trying to lock database"));
+            exit_status++;
+        }
+    }
+
     retval = krb5_db_iterate(util_context, name_pattern,
                              update_princ_encryption_1, &data);
     /* If exit_status is set, then update_princ_encryption_1 already
@@ -1058,6 +1068,8 @@ kdb5_update_princ_encryption(int argc, char *argv[])
         com_err(progname, retval, _("trying to process principal database"));
         exit_status++;
     }
+    if (!data.dry_run)
+        (void)krb5_db_unlock(util_context);
     (void) krb5_db_fini(util_context);
     if (data.dry_run) {
         printf(_("%u principals processed: %u would be updated, %u already "