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 kitten? > >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