| From: | ghudson@mit.edu |
| Subject: | SVN Commit |
Fix lock inconsistency in ctx_unlock()
The lock inconsistency fixed here is quite possibly the same as
described in https://bugzilla.redhat.com/show_bug.cgi?id=586032 .
The problem is that ctx_unlock() fails to unlock the principal DB if
it fails to unlock the policy DB, and this happens when ctx_lock()
fails to lock the policy DB (likely because the caller is racing
against a kdb5_util load, which will be using a "permanent" lock,
meaning that the lock file will be unlinked after acquiring the
lock). The fix is to perform both unlock operations *then* handle
any errors that either or both might have returned.
Additionally, we don't really need or want to use non-blocking locks,
and we certainly don't want to sleep(1) in krb5kdc (possibly several
times, as there was a loop over this) when either of the principal or
policy DB is locked. Some callers still request non-blocking locks,
and ctx_lock() still honors this.
https://github.com/krb5/krb5/commit/29ee39baa919361ae08e26caab896890d5cb3eb4
Author: Nicolas Williams <nico@cryptonector.com>
Committer: Greg Hudson <ghudson@mit.edu>
Commit: 29ee39baa919361ae08e26caab896890d5cb3eb4
Branch: master
src/plugins/kdb/db2/kdb_db2.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)