gss_display_status question

[Ken Raeburn]

On Mar 16, 2009, at 16:50, Tom Anderberg wrote:
> I work on a security library that provides access to Kerberos through
> GSS-API. We are trying to log Kerberos errors using  
> gss_display_status. We
> have noticed that the same error code can, at different times, produce
> either a helpful or an unhelpful error message. Sometimes this seems  
> to
> depend on the Kerberos operations that have been performed.
>
> For example:
>    - Call gss_display_status with 0x96c73a22 and get "Unknown code  
> krb5 34"
>    - Then call gss_acquire_cred (doesn't matter if it succeeds or  
> fails)
>    - Repeat the initial call to gss_display_status and get "Request  
> is a
>      replay"

If you call gss_display_status as the first Kerberos-related thing in  
the process (or first thing after doing a dlopen to access the  
Kerberos library), yes, I'd expect this.  Setting up access to the  
error table strings is part of the library initialization code for  
whichever library contains the error table in question.  For start-up  
performance reasons, we delay this initialization until the first time  
certain "interesting" operations are invoked, like krb5_init_context,  
but any path that should be able to return such error codes should  
cause the initialization to be done.  If that's not happening, it's a  
bug.

We didn't really anticipate that people would be printing out error  
codes supplied from outside the process, without doing Kerberos- 
related calls first.  If that's your use case, perhaps we need to fix  
something...

(There are also library finalization functions, implemented in an OS- 
specific manner, which will discard the dynamic storage allocated by  
the library init function and other global storage used by the  
library.  So dlclose on a dynamically loaded Kerberos library will do  
the cleanup, and if you do dlopen on it again, the library internals  
are again in the uninitialized state.)

> However, there are platforms (such as Linux) where we always just get
> "Unknown code".

Even after doing Kerberos library calls?  That's probably a bug.   
(Though if you're passing in an error code from outside the process,  
and gss_acquire_cred doesn't call into the Kerberos library for  
whatever reason, it would be the expected result.)

> Is there something that we need to do to initialize Kerberos before  
> calling
> gss_display_status? Or is there some other explanation?

Most of the normal uses of the Kerberos library should do the  
initialization, as I said.  Perhaps you can describe how you're using  
it, if your usage is something unusual?

Ken