gss_display_status() bug dealing with minor/mech specific error codes?
will.fiveash at oracle.com
Wed Apr 24 19:11:13 EDT 2013
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
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
Oracle Solaris Software Engineer
More information about the krbdev