e-type / kvno processing in 1.8
Greg Hudson
ghudson at MIT.EDU
Tue Sep 28 15:09:24 EDT 2010
On Mon, 2010-09-27 at 15:03 -0400, Tim Metz wrote:
> At first pass, the problem at least has the appearance that it could be
> related to kvno processing code. More specifically, in versions prior
> to 1.8 if a kvno=0 contained an unsupported encryption type, processing
> would continue to kvno=1 and succeed. Starting with version 1.8, it
> looks like if kvno=0 has an unsupported e-type, processing fails, and
> does not continue on to consult kvno=1.
I think I see what changed here; it's a side effect of the change I made
in r23599 to make krb5_dbe_def_search_enctype more consistent about when
it returns KRB5_KDB_NO_PERMITTED_KEY.
I've checked in the following fix, which is to treat
krb5_c_enctype_compare errors as non-fatal. If the ktype argument is
invalid, no kvno will match and the function will eventually return
KRB5_KDB_NO_MATCHING_KEY, which I think is fine; if the key entry
enctype is invalid, then we'll move on to the next key entry as we used
to do (more by accident than by design, but it's reasonable behavior).
This should eventually get pulled up to the 1.8.4 patch release, but we
don't currently have a plan for when that will go out.
Index: kdb_default.c
===================================================================
--- kdb_default.c (revision 24369)
+++ kdb_default.c (working copy)
@@ -91,12 +91,10 @@
/* Match this entry against the arguments. */
if (ktype != -1) {
- if ((ret = krb5_c_enctype_compare(kcontext, (krb5_enctype) ktype,
- dbentp->key_data[i].key_data_type[0],
- &similar)))
-
- return(ret);
- if (!similar)
+ ret = krb5_c_enctype_compare(kcontext, (krb5_enctype) ktype,
+ dbentp->key_data[i].key_data_type[0],
+ &similar);
+ if (ret != 0 || !similar)
continue;
}
if (stype >= 0 && db_stype != stype)
More information about the Kerberos
mailing list