[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using GSSAPI without implicit static/global variables
>>>>> "Andrew" == Andrew Bartlett <firstname.lastname@example.org> writes:
Andrew> I've been looking more and more at using Heimdal's GSSAPI
Andrew> layer to replace the hacked up version we have in Samba4.
Andrew> However, we have a strong move against global variables,
Andrew> due to the possible use of threads (and a general distrust
Andrew> of them...).
Andrew> The particular use case I'm worried about is when we have
Andrew> the client libraries used in a threaded manner, such that
Andrew> two different kerberos principals are being used to
Andrew> contact two different servers. It would seem impossible
Andrew> to do this in a thread-safe manner, because at the very
Andrew> least, the ccache is tied to the gss_krb5_context, and is
Andrew> therefore a global variable. Even without threads, it
Andrew> looks messy to swtich around the ccache before all the
Andrew> respective calls.
I'd recommend tieing the ccache to the gssapi credentials.
Andrew> It would seem a logical extension that
Andrew> gss_init_sec_context() should match MIT 1.4, which allows
Andrew> the caller to specify a security context to the first
Andrew> pass. (I could then add another function to setup this
Andrew> context correctly).
I don't understand what behavior you are describing here. If you are
saying that MIT Kerberos allows you to pass in a non-null context to
the first call to gss_init_sec_ctx, we consider that a bug and would
ask you not to rely on it.
What we recommend people do who need to care about treading issues is
to set up credentials, then to call gss_init_sec_ctx. (I'm not quite
sure that the routine you want to expose to set the ccache on the
credentials is exposed in MIT Kerberos, but that's certainly the
direction we'd like to see people go in).