[11426] 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:53:33 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-32533.9.03788849351251@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:53:31 -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
After further discussion, there are three acceptable options here:
1. gss_inquire_sec_context could call into the mech to get the mech type.
2. gss_union_ctx_id_desc could be extended to contain an actual_mech
field, which could be remembered from the mech's init/accept_sec_context
invocation, and gss_inquire_sec_context could return that.
3. We could do the unwrapping: the mechglue would assume that if the
mech's init/accept_sec_context invocation returns a different mech_type
from req_mech_type, then *context_handle is a union context. The
mechglue would then update the mech_type field of its own union context
to match the returned mech type (as your patch does) and would change
the internal_ctx_id of its own union mech to the internal_ctx_id of the
union context returned by the mech.
The net effect of any of these changes would be for gss_inquire_context
to return the correct (actual) mech type for a context negotiated by
SPNEGO. With that fixed, presumably your error message display problems
should also be solved.
We've hit code freeze for 1.8, but I think any of these would be
reasonable for inclusion in 1.8.1, which is probably only a month or so off.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
