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

[Will Fiveash]

On Wed, Apr 24, 2013 at 06:38:02PM -0500, Nico Williams wrote:
> On Wed, Apr 24, 2013 at 6:11 PM, Will Fiveash <will.fiveash at oracle.com> wrote:
> > 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.
> 
> RFCs 2743 and 2744 don't say that the implementation MUST (nor SHOULD)
> allow the app to display arbitrary minor status codes either, only
> ones returned to the application by the API.

Actually 2744 states:

   Allows an application to obtain a textual representation of a GSS-API
   status code, for display to the user or for logging purposes.

It does not say "returned by a preceding GSS-API function call".

> MIT dynamically assigns minor status codes in order to provide better
> functionality when using, e.g., SPNEGO, and better error strings for
> the other mechanisms too.

So you think it is reasonable that gss_display_status() when called like
so with the GSS_C_MECH_CODE and the krb mech specified:

gss_OID_desc krb_mech_OID = {9, "\052\206\110\206\367\022\001\002\002"};

gss_display_status(&minor_return_status, KRB5_FCC_PERM, GSS_C_MECH_CODE,
            &krb_mech_OID, &more, &status_string);

return an error from gssint_mecherrmap_get() instead of going ahead and
calling mech->gss_display_status() which does the right thing in this
particular instance?  Note that before the introduction of
gssint_mecherrmap_get() in gss_display_status() the above worked as
expected without a preceding libgss function call to initialize
anything.

> >> 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.
> 
> Yeah, that's true.  You'll probably want a USDT provider to make the
> display strings available to DTrace.  (Really, truss(1)?  pfft, when
> you have DTrace?!)   :) :)

I still find truss useful.  8^) 

-- 
Will Fiveash
Oracle Solaris Software Engineer