Skip Menu |

Subject: SVN Commit
Download (untitled) / with headers
text/plain 1.2KiB

Fix lock inconsistency in ctx_unlock()

The lock inconsistency fixed here is quite possibly the same as
described in .

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.
Author: Nicolas Williams <>
Committer: Greg Hudson <>
Commit: 29ee39baa919361ae08e26caab896890d5cb3eb4
Branch: master
src/plugins/kdb/db2/kdb_db2.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
The message for this commit incorrectly contains a paragraph from the
previous commit (b858e776ece87756202d4c646931d35bd407e3ea) about not
using non-blocking locks. That paragraph should be ignored.
To: rt@krbdev.MIT.EDU
Subject: [ #7360] hypothesized trigger conditions
From: Tom Yu <>
Date: Thu, 05 Sep 2013 20:20:25 -0400
libkadm5 locks only the policy database when updates to the policy
database. One possible trigger condition is:

* create_principal gets write lock on policy db to update policy

* krb5kdc races against this, trying to read-lock both principal db
and policy db (krb5_db2_get_principal gets locks on both)

** the principal db lock succeeds, but policy db lock fails

** error path in krb5_db2_lock calls krb5_db_unlock, which fails to
unlock the non-locked policy db, and due to this bug, skips the
code to unlock the principal db

* krb5kdc ends up with a persistent read lock on the principal db

Another possibility is lockout updates by the KDC racing against
policy lookups (from password changes) by kadmind.