[11469] in Kerberos-V5-bugs
[krbdev.mit.edu #6650] SVN Commit
daemon@ATHENA.MIT.EDU (Tom Yu via RT)
Mon Mar 22 21:31:33 2010
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Tom Yu via RT" <rt-comment@krbdev.MIT.EDU>
In-Reply-To: <rt-6650@krbdev.mit.edu>
Message-ID: <rt-6650-32634.14.6049679823434@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #6650'":;"'AdminCc of krbdev.mit.edu Ticket #6650'":;@MIT.EDU
Date: Mon, 22 Mar 2010 21:31:31 -0400 (EDT)
Reply-To: rt-comment@krbdev.MIT.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
pull up r23676 from trunk
------------------------------------------------------------------------
r23676 | ghudson | 2010-01-28 13:39:31 -0800 (Thu, 28 Jan 2010) | 17 lines
ticket: 6650
subject: Handle migration from pre-1.7 databases with master key kvno != 1
target_version: 1.7.1
tags: pullup
krb5_dbe_lookup_mkvno assumes an mkvno of 1 for entries with no
explicit tl_data. We've seen at least one pre-1.7 KDB with a master
kvno of 0, violating this assumption. Fix this as follows:
* krb5_dbe_lookup_mkvno outputs 0 instead of 1 if no tl_data exists.
* A new function krb5_dbe_get_mkvno translates this 0 value to the
minimum version number in the mkey_list. (krb5_dbe_lookup_mkvno
cannot do this as it doesn't take the mkey_list as a parameter.)
* Call sites to krb5_dbe_lookup_mkvno are converted to
krb5_dbe_get_mkvno, except for an LDAP case where it is acceptable
to store 0 if the mkvno is unknown.
http://src.mit.edu/fisheye/changelog/krb5/?cs=23822
Commit By: tlyu
Revision: 23822
Changed Files:
U branches/krb5-1-7/src/include/kdb.h
U branches/krb5-1-7/src/kadmin/dbutil/kdb5_mkey.c
U branches/krb5-1-7/src/lib/kadm5/srv/svr_principal.c
U branches/krb5-1-7/src/lib/kdb/kdb5.c
U branches/krb5-1-7/src/lib/kdb/libkdb5.exports
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
