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.
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.