gss_display_status() bug dealing with minor/mech specific error codes?

[Will Fiveash]

On Tue, Apr 23, 2013 at 10:29:35PM -0400, Greg Hudson wrote:
> On 04/23/2013 06:51 PM, Will Fiveash wrote:
> > I think there is a bug in MIT's gss_display_status() when dealing with
> > mech specific minor codes.  Here is my test program:
> 
> Our mechglue's gss_display_status can only translate minor codes which
> were returned from another GSSAPI function within the same process.

Looking at the description of gss_display_status in RFC 2744 I do not
see where the usage restriction you describe above is mentioned.

> It's not a translation facility for error codes returned from libkrb5
> functions or plucked from libkrb5's com_err tables, even if you supply
> the krb5 mech OID as the req_mech_type parameter (which we ignore).

We have found it useful when trussing apps that use gss as truss reveals
major and minor codes as hex numbers to have a simple utility to call
gss_display_status() on those codes.

Beyond that, why ignore the req_mech_type if it is provided?  Again from
RFC 2744:

mech_type         Object ID, read, optional
                  Underlying mechanism (used to interpret a
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                  minor status value) Supply GSS_C_NO_OID to
                  ^^^^^^^^^^^^^^^^^^
                  obtain the system default.

My expectation is if gss_display_status() is given GSS_C_MECH_CODE and
the krb5 mech OID for the mech_type then that's what it should use when
calling mech->gss_display_status().

-- 
Will Fiveash
Oracle Solaris Software Engineer