[krbdev.mit.edu #7861] iprop can deadlock on master KDC

[Greg Hudson via RT]

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.