[1016] in Kerberos_V5_Development
GSS-API's use krb5 context
daemon@ATHENA.MIT.EDU (Sam Hartman)
Mon Feb 26 18:16:24 1996
Date: Mon, 26 Feb 1996 18:16:11 -0500
From: Sam Hartman <hartmans@MIT.EDU>
To: krbdev@MIT.EDU
Because a static declarion of kg_context in k5mech.c (see my
next checkin) broke the build of the krb5 locker today, I started
looking at the way contexts are used.
Apparently, GSS-API tends to use one or at least a very few
number of krb5 contexts, certainly not enough to be thread safe. This
is unfortunate, but not surprising; what bothers me is an apparent
tendency to move away from using contexts as appropriate, towards a
static context (kg_context) (see the following ChangeLog entry).
I'm almost certainly missing something as I have only looked
at this for about five minutes, but I would be curious about what
we're trying to do, and about how GSS-API uses krb5_contexts.
--Sam
Sat Sep 16 03:18:02 1995 Theodore Y. Ts'o <tytso@dcl>
* gssapiP_krb5.h: Remove context and cred from the gssapi security
context, as they aren't needed. kg_seal and kg_unseal now
take a krb5_context argument.
* ser_sctx.c (kg_ctx_size, kg_ctx_externalize,
kg_ctx_internalize): No longer serialize the context and
cred fields of the gssapi security context.
* krb5_gss_glue.c: Don't rely on the context field of the gssapi
security context. Use kg_context instead.
* verify.c (krb5_gss_verify, krb5_gss_verify_mic):
* unseal.c (krb5_gss_unwrap, krb5_gss_unseal):
* sign.c (krb5_gss_sign, krb5_gss_get_mic):
* seal.c (krb5_gss_seal, krb5_gss_wrap):
* process_context_token.c (krb5_gss_process_context_token):
* k5unseal.c (kg_unseal):
* k5seal.c (kg_seal_size): Add a krb5_context argument to this
function, so we don't have to depend on the context field
in the gssapi security context.
* init_sec_context.c (krb5_gss_init_sec_context): Don't initialize
the context and cred fields in the gssapi security
context. Copy ctx->subkey to ctx->seq.key, so they are
separately allocated.
* gssapi_krb5.c (kg_get_context): When initialize kg_context, call
krb5_init_ets() so that the error tables are initialized.
