krb5 1.9.1 gss_accept_sec_context() returning major=851968 minor=100001

[Adam McLaurin]

Hi Greg,

Thanks for the reply. I assume you mean gss_display_status(), and
unfortunately it's not able to map the 'fake' code back to any
meaningful string.

Perhaps I'm calling it wrong? Here's what I'm doing:
gss_display_status(&minor, status, type, GSS_C_NULL_OID, &mctx, &msg);

... where 'status' is the minor status code '100001' and 'type' is
'GSS_C_MECH_CODE'.

Any advice on where to go from here?

Thanks again,
Adam


On Thu, Sep 27, 2012, at 05:05 PM, Greg Hudson wrote:
> On 09/27/2012 01:20 PM, Adam McLaurin wrote:
> > If it helps, I noticed by running my application in GDB that the value
> > of '*minor_status' inside gss_accept_sec_context() at the point of
> > function return is 2529639056 ("Wrong principal in request"), but after
> > the function returns my application thinks the value is 100001. I have
> > no idea how this mismatch could occur. This is a C++ application running
> > on 64-bit Linux, in case it matters.
> 
> If our mechglue sees the same minor code returned by two different
> mechs, it maps the second code to a value like 100001.  Because of the
> four different krb5 mech OIDs and SPNEGO, minor code collisions happen
> in practice more often than one might expect.
> 
> gss_display_name() should be able to map the fake code number back to
> the original mech and minor code, and from there to the appropriate
> error message.  If it's not doing so in your case, we'll need more
> details to figure out why.
>