Notes on lost extended error messages for kinit -k

[Nico Williams]

On Thu, Jun 30, 2011 at 9:25 AM, Jeffrey Altman
<jaltman at secure-endpoints.com> wrote:
> On 6/30/2011 1:20 AM, ghudson at MIT.EDU wrote:
>> * 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.
>>
>
> I think it is the responsibility of code such as this to save context
> and restore it as necessary.
>
> The krb5_get_init_creds_keytab() case is flawed for another reason.  The
> force retry to master call is made regardless of whether or not there is
> a master defined.  As a result it is impossible for
> krb5_get_init_creds_keytab() to know whether or not the error state from
> the second call is more or less meaningful than the first.
>
> If this code were to be restructured, I would have a function that
> determines whether or not there are masters defined and only make the
> second call if there are.  Secondly, the master list should be cached so
> that the cost of dns lookups is not repeated.

+1.  But also, there's something to be said for reporting (merging)
all the error cases in fallback handling when all fallbacks fail,
since two different errors might both be meaningful.  I grant that
fallbacks that fail differently are likely to be rare, but they would
still be useful to be able to observe.

Nico
--