Return-Path: <tlyu@mit.edu>
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) by krbdev.mit.edu (Postfix) with ESMTPS id 732CE3F2DA for <rt@krbdev.MIT.EDU>; Thu,  5 Sep 2013 20:20:25 -0400 (EDT)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r860KPwv022406; Thu, 5 Sep 2013 20:20:25 -0400 (EDT)
To: rt@krbdev.MIT.EDU
Subject: [krbdev.mit.edu #7360] hypothesized trigger conditions
From: Tom Yu <tlyu@mit.edu>
Date: Thu, 05 Sep 2013 20:20:25 -0400
Message-ID: <ldvr4d2ztpy.fsf@cathode-dark-space.mit.edu>
Lines: 19
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
RT-Send-Cc: 
X-RT-Original-Encoding: us-ascii
Content-Length: 743

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
  refcount

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