Re: Using GSSAPI without implicit static/global variables

[Luke Howard <lukeh@PADL.COM>]

>The particular use case I'm worried about is when we have the client
>libraries used in a threaded manner, such that two different kerberos
>principals are being used to contact two different servers.  It would
>seem impossible to do this in a thread-safe manner, because at the very
>least, the ccache is tied to the gss_krb5_context, and is therefore a
>global variable.  Even without threads, it looks messy to swtich around
>the ccache before all the respective calls.

A credentials cache is associated with a GSS credentials handle, not a
context. But it's true that there is no way to bind a ccache to a cred
handle without calling gss_krb5_ccache_name(), for which calls must be
serialized.

>What I'm wondering (with regard to global variable elimination) is:
> - Has this been tried before (and found some insurmounable obstacle?)
> - Is this something that would be accepted back upstream?
> - How does this interact with the port of MIT's mechglue that PADL has
>done?

I think making gssapi_krb5_context per-context could be a little tricky,
because you need it for other APIs that don't take a context handle. I
think what you really want something like gss_set_sec_context_option()
for credential handles.

-- Luke

--