Generic unknown RC/IO error while verifying initial ticket

Ken Hornstein kenh at cmf.nrl.navy.mil
Wed Dec 1 12:45:10 EST 2004


>    >> Would you be interested in helping design a way to do this?
>    >> Heimdal allows an error string to be stored inside a context
>    >> and retrieved later.  That gives you enough flexibility to
>    >> store the file name etc.  The complexity is that we would need
>    >> to go through the code and find every place where we have an
>    >> error return and at least clear that string so the error
>    >> returned always corresponded to the string if it was set.
>
>    Douglas> Tag the string with the error code too, so only clear it
>    Douglas> if the error code to be reported to the user does not
>    Douglas> match the error with the message.
>
>Yeah, that works. It means the user has to pass in both a context and
>an error code to get the (possibly enhanced) error string.
>
>I think having to pass in an eventually unnecessary error code is an
>acceptable price to pay for reasonable error reporting from krb5.

So, I'm trying to understand how this would work from an API perspective.

Would this simply be hooked into com_err and friends?  I ask because I
thought there was a goal of being able to use a third-party supplied
com_err library with MIT Kerberos (but maybe I'm thinking about
OpenAFS).  I don't particularly care about that goal myself, but I
wanted to know if the intention was to continue to use the com_err API
or provide a new library function?  I have a lot of code which uses
com_err, and it sure would suck to have to change it.

--Ken


More information about the Kerberos mailing list