[2464] in Kerberos-V5-bugs
krb5-libs/198: "no matching kvno in keytab" error code?
daemon@ATHENA.MIT.EDU (bjaspan@MIT.EDU)
Fri Nov 15 14:13:06 1996
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: krb5-unassigned@RT-11.MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, bjaspan@MIT.EDU
Date: Fri, 15 Nov 1996 14:11:32 -0500
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
>Number: 198
>Category: krb5-libs
>Synopsis: "no matching kvno in keytab" error code?
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Nov 15 14:12:01 EST 1996
>Last-Modified:
>Originator: Barry Jaspan
>Organization:
mit
>Release: 1.0-development
>Environment:
System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc
>Description:
When a program searches for a keytab entry but does not find one with
the right kvno, it returns the same error as if the principal did not
appear in the keytab at all. I think this confuses users, and adds a
step to diagnosing many problems. Error codes are cheap, so I suggest
we add
KRB5_KT_KVNONOTFOUND, "Key table entry with correct kvno not found"
that can be returned by the keytab library. The error could would
explicitly mean that at least one matching principal entry was found
but with the wrong kvno. The text string could probably be better
worded.
This of course is a feature change, not a bug fix, and we're in
feature freeze for 1.0. Too bad, given the number of users having
this problem with the kadmind keytab.
>How-To-Repeat:
>Fix:
>Audit-Trail:
>Unformatted:
