On Mon, 29 Oct 2012, Jeffrey Hutzelman wrote:
On Mon, 2012-10-29 at 16:57 -0500, Andrew Deason wrote:
commit c23fc51c268fefc460b224a12b63cd9a9672b538
Author: Ben Kaduk <[email protected]>
Date: Wed Oct 24 23:21:29 2012 -0400
Describe the GSSNegotiate errorcode field
I wasn't quite sure on what kind of errors are expected here. If they
are what you wrote in this commit, then I think it makes sense to make
this application-specific, and in rxgk-afs we specify a registry to
specify values (or if we want to keep it implementation-private or
something, that's an option, too).
But if this is intended to contain GSS error codes... aren't those
standard? (and don't we need more than one 4-byte int for that?)
GSS-API major status codes are standardized at the abstract API layer as
integers, but without specific values. The actual integer values used
depend on the language bindings; for C they are specified in RFC2744,
but for other programming languages the values might be different.
GSS-API minor status codes are not standardized; they are specific to
the mechanism and implementation.
So, you can't depend on doing anything programmatic with GSS-API status
codes you receive from a peer. However, it turns out that in practice,
the status codes (or better yet, the set of status strings returned by
GSS_Display_status) can be very useful in troubleshooting.
This field is explicitly *not* a GSS error code, if I understand
correctly. It is embedded within te RXGK_ClientInfo struct, which is
returned to the client in the rxgk_info (out) parameter of GSSNegotiate().
The value of the rxgk_info field is undefined if the gss_major_status
(out) parameter of GSSNegotiate() is not equal to GSS_S_COMPLETE.
So, the GSS error codes would all be in gss_major_status and
gss_minor_status -- the errrorcode field of RXGK_ClientInfo is for policy
errors. It was remarked (I don't remember by whom offhand) that we should
give some guidance for what values might be seen in this field; my
interpretation of it as policy errors is that the policy is
application-specific. Even so, it seems appropriate to give some sense
for what conditions applications might consider to be policy errors.
I am not strongly tied to this text, or even to having the errorcode field
be defined to hold application-specific values. If someone wants to
advocate having a registry for these values established in this document,
we can talk about that, but policy does feel application-specific to me.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
