From 1c65092f874edc41c02f328608e2e44a93a6fb89 Mon Sep 17 00:00:00 2001 From: Greg Hudson Date: Wed, 31 Jul 2013 18:49:13 -0400 Subject: 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) --- src/kadmin/dbutil/kdb5_mkey.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/kadmin/dbutil/kdb5_mkey.c b/src/kadmin/dbutil/kdb5_mkey.c index 4edacb624..0fbbb78ed 100644 --- 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 " -- cgit