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

Re: Using GSSAPI without implicit static/global variables

>>>>> "Andrew" == Andrew Bartlett <abartlet@samba.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).