Notes on lost extended error messages for kinit -k

[ghudson@MIT.EDU]

If you run kinit -k for a principal which isn't in your keytab, you
may get:

  equal-rites$ kinit -k user at KRBTEST.COM
  kinit: Key table entry not found while getting initial credentials

What you should see is "No key table entry found for user at KRBTEST.COM
while getting initial credentials", because (since 1.9) an extended
error is set in kt_file.c:krb5_ktfile_get_entry().  Here's why the
error message is lost in common configurations:

1. krb5int_get_init_creds() returns with use_master set to 0.  This
happens if, for instance, the KDCs for the realm are configured in
krb5.conf but no master_kdc entry is set.

2. It then retries the request with user_master set to 1, in case the
first request was to an out-of-date slave.

3. Near the beginning of the krb5int_get_init_creds process,
fast.c:krb5int_fast_as_armor() calls krb5_clear_error_message().  I've
talked with Sam about when to clear the error message, and his design
principle was "often enough to make sure than an extended message does
not get applied to a later instance of an error".

4. Instead of repeating the same error condition as the original call
to krb5int_get_init_creds(), the second attempt fails with
KRB5_REALM_UNKNOWN because the code can't figure out the master KDC
for the realm (it will try a SRV lookup for _kerberos-master, which
usually doesn't exist).

This problem could be attacked from several angles:

* The retry could be avoided if we declared that in a realm with kdc
  entries and no master_kdc entry, the first kdc entry is the master.
  I have an old ticket about this, #6782, but haven't gotten around to
  making it happen.  (On a tangential note, it would be nice if
  krb5_sendto_kdc() could set the use_master flag without making a
  second call to k5_locate_kdc(), by remembering whether a serverlist
  entry is the master when possible.)

* Perhaps krb5_get_init_creds_keytab() should save the error message
  before the retry, and put it back if it decides to use ret instead
  of ret2.  Perhaps we want convenience functions to make this easier
  to do.

* Perhaps krb5int_fast_as_armor() shouldn't be clearing the error
  message.  My reaction to Sam's design principle was that you want to
  clear an error message after you've handled an error without
  returning it, not just any time you're beginning a non-trivial
  sequence of operations.  Of course, the gic_keytab fallback is a
  case where we're handling an error without returning it, so my
  interpretation of the design principle would mean we'd have to look
  more closely at that code.

I'm mostly just putting these thoughts in writing before I turn to
other issues.