Skip Menu |
 

Download (untitled) / with headers
text/plain 3.7KiB
From krb5-bugs-incoming-bounces@PCH.mit.edu Fri Feb 25 18:58:31 2011
Return-Path: <krb5-bugs-incoming-bounces@PCH.mit.edu>
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
by krbdev.mit.edu (Postfix) with ESMTP id 888943DC65;
Fri, 25 Feb 2011 18:58:31 -0500 (EST)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id p1PNwVbP007370;
Fri, 25 Feb 2011 18:58:31 -0500
Received: from mailhub-dmz-2.mit.edu (MAILHUB-DMZ-2.MIT.EDU [18.7.62.37])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id p1PMqV1h028858
for <krb5-bugs-incoming@PCH.mit.edu>; Fri, 25 Feb 2011 17:52:31 -0500
Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU
[18.9.25.13])
by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id p1PMp0ZS008574
for <krb5-bugs@mit.edu>; Fri, 25 Feb 2011 17:52:31 -0500
X-AuditID: 1209190d-b7cacae000000a14-6a-4d6832aec357
Received: from adler.unx.csupomona.edu ( [134.71.247.15])
by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with
SMTP id 58.26.02580.FA2386D4; Fri, 25 Feb 2011 17:52:31 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
by adler.unx.csupomona.edu (Postfix) with ESMTP id 007171000BF;
Fri, 25 Feb 2011 14:52:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at csupomona.edu
Received: from adler.unx.csupomona.edu ([127.0.0.1])
by localhost (adler.unx.csupomona.edu [127.0.0.1]) (amavisd-new,
port 10024)
with ESMTP id DllV-RDxxyVm; Fri, 25 Feb 2011 14:52:29 -0800 (PST)
Received: from peachpuff.unx.csupomona.edu (peachpuff.unx.csupomona.edu
[134.71.248.147])
by adler.unx.csupomona.edu (Postfix) with ESMTP id BF3271000A1;
Fri, 25 Feb 2011 14:52:29 -0800 (PST)
Received: by peachpuff.unx.csupomona.edu (Postfix, from userid 0)
id BA8D41A038; Fri, 25 Feb 2011 14:52:29 -0800 (PST)
To: krb5-bugs@MIT.EDU
Subject: kdb5_util mkey operations hit assertion when iprop is enabled
From: kacarstensen@csupomona.edu
X-send-pr-version: 3.99
Message-Id: <20110225225229.BA8D41A038@peachpuff.unx.csupomona.edu>
Date: Fri, 25 Feb 2011 14:52:29 -0800 (PST)
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Fri, 25 Feb 2011 18:58:29 -0500
Cc: bldewolf@csupomona.edu, henson@csupomona.edu
X-BeenThere: krb5-bugs-incoming@mailman.mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: kacarstensen@csupomona.edu
Sender: krb5-bugs-incoming-bounces@PCH.mit.edu
Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu


Show quoted text
>Submitter-Id: net
>Originator: kacarstensen
>Organization:
Cal Poly Pomona
Show quoted text
>Confidential: no
>Synopsis: kdb5_util mkey operations hit assertion when iprop is enabled
>Severity: serious
>Priority: medium
>Category: krb5-appl
>Class: sw-bug
>Release: 1.8.3
>Environment:

System: Linux peachpuff 2.6.34-gentoo-r10 #2 SMP Mon Sep 20 13:14:28 PDT 2010 x86_64 Intel(R) Xeon(TM) CPU 3.16GHz GenuineIntel GNU/Linux


Show quoted text
>Description:
An assertion is hit when using kdb5_util to perform operations related
to the master key if incremental propagation is enabled. For example,

peachpuff ~ # kdb5_util add_mkey
Creating new master key for master key principal 'K/M@TEST.CSUPOMONA.EDU'
You will be prompted for a new database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
kdb5_util: kdb_log.c:53: ulog_lock: Assertion `ulog != ((void *)0)' failed.
Aborted

We've observed this behavior with the add_mkey, use_mkey, and purge_mkeys
commands. In each case, the assertion is not hit if incremental propagation is
disabled in kdc.conf.

Show quoted text
>How-To-Repeat:
- Enable incremental propagation in kdc.conf.
- Attempt to use kdb5_util with the add_mkey, use_mkey, or purge_mkey
commands.

Show quoted text
>Fix:

The only workaround we're aware of is to disable incremental propagation while
modifying the master key, then re-enable it when finished.
At a surface level, the bug is that in the current design, ulog_map()
must be invoked by callers of kdb_put_principal(), and the kdb5_util mkey
commands don't do that.

I am concerned about this comment in the ulog_map() call from kdb5_util
load: "We don't want to take out the ulog out from underneath kadmind so
we reinit the header log." Are there iprop log contention issues with
modifying the KDB from multiple processes at once? (If so, we have a
problem with kadmin.local.) I need to check in with Ken on this.
From: ghudson@mit.edu
Subject: SVN Commit

Make sure ulog_map() is invoked whenever we open the database in
kdb5_util. Fixes all of the master key rollover commands in the
presence of iprop. Reported by kacarstensen@csupomona.edu.


https://github.com/krb5/krb5/commit/55c9a76384bff75f93ee7e602caccf07bd29f5c5
Commit By: ghudson
Revision: 24667
Changed Files:
U trunk/src/kadmin/dbutil/dump.c
U trunk/src/kadmin/dbutil/kdb5_util.c
I believe the bug and fix apply to 1.8 as well (and 1.7).
From: tlyu@mit.edu
Subject: SVN Commit

pull up r24667 from trunk

------------------------------------------------------------------------
r24667 | ghudson | 2011-02-26 21:35:04 -0500 (Sat, 26 Feb 2011) | 8 lines

ticket: 6875
tags: pullup
target_version: 1.9.1

Make sure ulog_map() is invoked whenever we open the database in
kdb5_util. Fixes all of the master key rollover commands in the
presence of iprop. Reported by kacarstensen@csupomona.edu.

https://github.com/krb5/krb5/commit/a4227a7e08059606172a0ab607bee915355331c0
Commit By: tlyu
Revision: 24674
Changed Files:
U branches/krb5-1-9/src/kadmin/dbutil/dump.c
U branches/krb5-1-9/src/kadmin/dbutil/kdb5_util.c