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

[Nico Williams]

On Wed, Apr 24, 2013 at 7:41 PM, Will Fiveash <will.fiveash at oracle.com> wrote:
> On Wed, Apr 24, 2013 at 06:38:02PM -0500, Nico Williams wrote:
>> 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".

Yeah, but minor status codes are not really defined.  RFCs 1964, 4121,
and 4178 define some symbolic minor status codes, but not numeric
ones.

>> 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:

Yes, I do think that's reasonable.  I get that it's annoying.  The
problem is that the mechglue has no idea what minor status code ranges
the mech is going to use, but to make some things work (e.g.,
gss_display_status() when SPNEGO returns an error) requires being able
to map error codes.  If the libgss SPI had some rules for reserving or
allocating minor status code namespace to the mechglue then what you
want could be made to work.

>> 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^)

Meh.