kadmin's ktremove can remove wrong entries when removing kvno 0

Because of 8-bit wraparound, keytabs can contain entries with kvno 0.
Because 0 is a distinguished kvno value for krb5_kt_get_entry(),
kadmin's remove_principal() winds up substituting the specified kvno
with the highest-numbered kvno of the specified principal in the
keytab.  Make sure not to perform this substitution when in
specified-kvno mode.

(This fix leaves behind a very minor bug where "ktrem principal 0"
returns silently, instead of producing an error message like it
normally would, if principal exists in the keytab but not at kvno 0.)

ticket: 6854

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@24611 dc483132-0cff-0310-8789-dd5450dbe970

diff --git a/src/kadmin/cli/keytab.c b/src/kadmin/cli/keytab.c
index 3a7867f46d9f6f9bb7bed12e00819ef03281ad49..d3c4a66a9b017067732459dad2317fb5a89d6ad3 100644 (file)
--- a/src/kadmin/cli/keytab.c
+++ b/src/kadmin/cli/keytab.c
@@ -398,7 +398,8 @@ remove_principal(char *keytab_str, krb5_keytab keytab,
     }
 
     /* set kvno to spec'ed value for SPEC, highest kvno otherwise */
-    kvno = entry.vno;
+    if (mode != SPEC)
+        kvno = entry.vno;
     krb5_kt_free_entry(context, &entry);
 
     code = krb5_kt_start_seq_get(context, keytab, &cursor);