[1017] in Kerberos_V5_Development
Re: GSS-API's use krb5 context
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Mon Feb 26 20:29:24 1996
Date: Mon, 26 Feb 1996 20:29:17 -0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: Sam Hartman <hartmans@MIT.EDU>
Cc: krbdev@MIT.EDU
In-Reply-To: Sam Hartman's message of Mon, 26 Feb 1996 18:16:11 -0500,
<199602262316.SAA24331@tertius.mit.edu>
I have to run, so this message will have to be very short. The problem
is that the GSSAPI interface doesn't have in the API design the concept
of a library session context, ala the krb5_context.
It has a concept of a security context, but that's not the same thing.
Worse yet, some calls, such as gss_import_name(), don't take a security
context at all --- yet we need a krb5_context in order to service
things. Right now, all of the krb5 GSSAPI implementations take a void *
which they internally cast into a krb5_context.
Before we added the mechanism glue layer, we had to store the security
context somewhere, and the only place we could store it was the static
kg_context. Now that we have the mechanism glue layer, we can store the
krb5 context in the mechanism structure. (Of coruse, the mechanism
layer still has a static variable which points to the linked list of
mechanism structure. You can't win completely without making API
changes....)
There are still a few places which are using the static reference
kg_context. I agree making changes to avoid using kg_context, so we can
finally get rid of the context would be a good thing. However, given
the GSSAPI design, there will always be a static variable pointing to a
structure which will eventually point to a krb5 context, and yes, this
won't be thread safe. But you can't really do anything about this
without changing the GSSAPI. Given that a requirement was made that
GSSAPI v2 be backwards compatible with GSSAPI v1, and we didn't want to
duplicate all of the GSSAPI calls, it's not going to happen with GSSAPI
v2. Maybe for v3, if people really want it badly enough....
- Ted
