[22964] in Kerberos
Re: Generic unknown RC/IO error while verifying initial ticket
daemon@ATHENA.MIT.EDU (Ezra Peisach)
Wed Dec 1 16:19:21 2004
Date: Wed, 1 Dec 2004 14:22:22 -0500 (EST)
Message-Id: <200412011922.iB1JMM5f002711@contents-vnder-pressvre.mit.edu>
From: Ezra Peisach <epeisach@mit.edu>
To: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
Hmm - without much code changes from the external API....
a) There could be a new function krb5_get_extended_error_text - or
something like that - to retreive the extended message...
b) There would be an equivalent function to create an extended error
message. (thread specific context?)
c) When the error table is initialized - install a com_err_proc that
will query the extended error and format it nicely. If an extended error
is not present - don't display.
This would not require any "user" level changes then.
But - here are the issues:
If I have a call chain of a->b->c. If (c) registers an error - sets the
extended error code and returns to (b) - should (b) then be able to
register it's own complaint and extended error - or would that mask
(c)'s message. We sort of need a stack... Upon entry to a high level
kerberos function - the error stack would then need to be
cleared at critical juncture... Otherwise - the call stack is sort of
meaningless - as errors will be added - but never cleared...
For instance - before the (a)->(b)->(c) - the client code invoked (d) -
which returned an error (say credential not found)... The client code
was smart - and expected such an error - and then did the a-b-c route
when it encountered the next error - and calls com_err. Reporting the
error stack would then display (d) - which is not relevant.
So - we would need to be careful... A stack will give the most details -
and prevent masking the underlying problems - with a cost in that all
entry paths need to be understood. The tradeoff of a single extended
error has the risk of masking the error with a higher level message.
Ezra
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
