[6] in GSSAPI Development
Testing and stuff
daemon@ATHENA.MIT.EDU (John Wray, Secure Systems Developm)
Fri Apr 26 10:16:51 1991
Date: Fri, 26 Apr 91 07:16:10 PDT
From: "John Wray, Secure Systems Development, DTN 226-6106 26-Apr-1991 0905" <wray@ultra.enet.dec.com>
To: gssapi-dev@ATHENA.MIT.EDU
The most important purpose of this message is to see if anyone gets it! If
anyone at Athena receives it, could you please respond. Thanks!
My mail adddress is WRAY@ultra.enet.dec.com.
Now, regarding the various messages that have been flying around...
>From: DSMAIL::"decwrl::tytso@ATHENA.MIT.EDU" 24-APR-1991 14:40:10.90
>To: gssapi-dev@ATHENA.MIT.EDU
>CC:
>Subj: GSSAPI errors
>
>I've discussed this before, but I believe the #define's of the errors
>(on page 11 of draft C of the C bindings spec) should be in upper case,
>since that's a pretty standard C convention.
I don't have a very strong preference in this area. The convention is for
#defines to be in upper-case, although the GSSAPI is using #defines where
constant declarations would be better (for compilers that support them), and
the conventions for constants are less firm. As I said, I don't have a strong
preference, so unless there are objections, we might as well upper-case the
error status names. Does anyone else feel strongly on this issue?
>One other item which is a bit more important: I am uncomfortable with
>the names of the calling erros, the routine errors, and the
>supplementary status bits. They all begin with GSS_S, and they
>represent small numbers.
>
>/*
>...
>
>
>The problem with this scheme is that there's nothing to indicate that
>this expression will do something other than what a programmer would
>expect:
>
> if (gss_calling_error(retval) == GSS_S_BAD_MECH) {
> ...
> }
>I propose that we rename the error codes so that the error codes use a
>prefix GSS_CE for calling errors, GSS_RE for routine errors and GSS_SS
>for supplementary status bits. Comments?
Hmm. That's annoying. How about making the #defines give the real values of
the errors, not shifted right, rather than the values within the field, and
adjust the field extraction macros to do likewise. This would mean that the
condition in the fragment above would always be false. That would eliminate
this problem with less of a change. Comments?
>gss_acquire_cred should have an error code which means that it couldn't
>find credentials for the desired name. None of the error codes,
>GSS_RE_BAD_MECH, GSS_RE_BAD_NAMETYPE, or GSS_RE_BAD_NAME are quite what
>we want.
The intention is that GSS_S_FAILURE should be returned in this case. The
application has no business distinguishing between there being no credentials
to acquire under a given name, and there being no credentials that it is
authorized to acquire. Thus the generic error message is used in all failure
cases here.
>By the way, when should I expect to see the next draft of the GSS API C
>bindings spec?
I'll try to get a spec out sometime next week.
>Also, could I get some confirmation from the DEC folks that they are
>receiving this mailing list correctly? After some of my recent problems
>with the DEC mail system, I don't think I should trust it any further
>than I can throw the entire VMS documentation set.... :-)
I've been getting messages from the mailing list. I don't know whether I've
received all that's been sent though. I've had problems replying to messages
sent via the dsmail relay, but since that just forces me to use the list, I'll
consider it a feature rather than a bug :-)
>In attempting to code gss_accept_sec_context, I ran into a problem.
>When Kerberos does a krb5_rd_req(), it requires the sender's network
>address, and there's no place to pass that into gss_accept_sec_context.
There's some history involved in this issue - John Linn had better take this
one.
John
