[krbdev.mit.edu #6604] issues with gss_inquire_context and gss_display_context when using SPNEGO

[Arlene Berry via RT]

Even if gss_init/accept_sec_context reported the actual mechanism it
still wouldn't work.  What I'm seeing is that the top level glue layer
is returning fake minor status codes.  What happens is the krb5 function
returns an error code, the glue layer which called it calls map_error
for that error with the KRB5 mechanism and returns the error code to
SPNEGO.  SPNEGO returns the error code.  The top glue layer also calls
map_error but this time it calls it for the error with the SPNEGO
mechanism.  The mapping function doesn't find a mapping for the error
with SPNEGO but does find one for Kerberos so it makes up a fake error
code and returns the fake error code to the caller because error codes
are expected to be unique across all mechanisms.  The glue layer for
gss_display_status searches the cache of mapped error codes.  It uses
the associated mechanism from the cache and ignores the one that was
passed in.  The problem with this is that when using SPNEGO you will
always pass through the glue layer twice with two different mechanisms
with the result that a fake error code will always be returned to the
caller.  The concept of fake error codes is fundamentally flawed because
they are meaningless to the calling application which therefore cannot
respond to them.