Skip Menu |
 

Subject: iprop can deadlock on master KDC
On a master KDC with iprop enabled, krb5_db_put_principal and
krb5_db_delete_principal behave as follows:

* Lock the ulog
* Add an uncommitted update record to the ulog
* Perform the DB operation
* Finalize the update record
* Unlock the ulog

The DB2 back end implicitly locks the database during the database
operation, so the total effect is lock the ulog, lock the DB, unlock the
DB, unlock the ulog.

However, if a program obtains an explicit lock with krb5_db_lock and
then changes a principal, the order of lock acquisition is reversed (DB
before ulog). Depending on the kernel, this will result in either
actual deadlock, or an EDEADLK error and a failed operation.

This reversed acquisition order happens in two cases: kdb5_util
update_princ_encryption and kdb5_util load -update.
From: ghudson@mit.edu
Subject: git commit

Simplify iprop update locking and avoid deadlock

Since we are no longer treating the update log like a journal (#7552),
we don't need two-stage update logging. In kdb5.c, add an update log
entry after each DB change in one step, without getting an explicit
lock. In kdb_log.c, combine ulog_add_update with ulog_finish_update,
and make ulog_add_update lock the ulog internally.

This change avoids deadlock by removing the only cases where the ulog
is locked before the DB.

https://github.com/krb5/krb5/commit/444ef5fe9ec8d64a5db27b3a8aaf6813dd7ef0e0
Author: Greg Hudson <ghudson@mit.edu>
Commit: 444ef5fe9ec8d64a5db27b3a8aaf6813dd7ef0e0
Branch: master
src/include/kdb_log.h | 2 -
src/lib/kdb/kdb5.c | 116 ++++++++-----------------------------------------
src/lib/kdb/kdb_log.c | 59 ++++++++-----------------
3 files changed, 37 insertions(+), 140 deletions(-)