[16955] in Kerberos_V5_Development
Re: Notes on lost extended error messages for kinit -k
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Jun 30 17:06:00 2011
MIME-Version: 1.0
In-Reply-To: <4E0C8777.4070408@secure-endpoints.com>
Date: Thu, 30 Jun 2011 16:05:56 -0500
Message-ID: <BANLkTikQBu_NNhELHQcU0w_Qr8xiAjCZkw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: jaltman@secure-endpoints.com
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Thu, Jun 30, 2011 at 9:25 AM, Jeffrey Altman<jaltman@secure-endpoints.com> wrote:> On 6/30/2011 1:20 AM, ghudson@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 thatfallbacks that fail differently are likely to be rare, but they wouldstill be useful to be able to observe.
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
