[11425] in Kerberos-V5-bugs
[krbdev.mit.edu #6604] issues with gss_inquire_context and
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Thu Feb 25 14:04:46 2010
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Greg Hudson via RT" <rt-comment@krbdev.MIT.EDU>
In-Reply-To: <rt-6604@krbdev.mit.edu>
Message-ID: <rt-6604-32532.18.1844049181675@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #6604'":;"'AdminCc of krbdev.mit.edu Ticket #6604'":;@MIT.EDU
Date: Thu, 25 Feb 2010 14:04:43 -0500 (EST)
Reply-To: rt-comment@krbdev.MIT.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
I discussed this issue with Nico, our resident mechglue expert. Here
was the takeaway:
* There is no fundamental reason to unwrap the double-layered union mech
except perhaps performance (avoiding the two extra function calls for
each message operation).
* gss_inquire_sec_context should be returning the actual mechanism, so
that's a bug. (More on the best way to fix that later; we were
interrupted by lunch.)
* gss_display_status doesn't accept a context as an argument; it accepts
a mech. If the app is passing the correct mech to gss_display_status,
then the negotiated mech's error codes should be displayed correctly.
So if gss_inquire_sec_context is fixed, error codes should not be a
motivation for unwrapping the double-layered union context.
* If we did want to unwrap the double layering, the way to do it would
be to require mechs to return a union context if they set *actual_mech
(for init) or *mech_type (for accept) to a value other than the initial
mech type (for init) or the token mech type (for accept). We already do
something similar for delegated creds.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
