[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using GSSAPI without implicit static/global variables

On Sun, 2005-02-13 at 00:45 +1100, Luke Howard wrote:
> >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.

Assuming I create new calls that do all the things required to make this
sane, what is the correct forum to make them 'standard'.  I presume

> >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.

It certainly looks like a pain, but I'll give it a stab. :-)

Andrew Bartlett

Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

This is a digitally signed message part