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

[Nico Williams]

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.

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.

>> 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?!)   :) :)

Nico
--