How is an application supposed to know if a Kerberos library isthread safe?

Sam Hartman hartmans at MIT.EDU
Mon Dec 20 16:07:28 EST 2004


>>>>> "Jeffrey" == Jeffrey Altman <jaltman at columbia.edu> writes:

    Jeffrey> Nicolas Williams wrote:
    >> So the question is whether the darned thing is MT-safe; MT-hot
    >> is another issue and I'm not sure that that needs to be
    >> indicated.  Also, one would think that the entire GSS mechglue
    >> and all its mechs should be MT-safe -- if one mech isn't and
    >> the GSS mechglue doesn't work around that, then none of them
    >> are (think of concurrent calls to GSS_Acquire_cred() with
    >> GSS_C_NULL_OID_SET for desired_mechs).  The mechglue, after
    >> all, could maintain a global mutex for dealing with MT-unsafe
    >> mechs.  So, the right function prototype perhaps shouldn't have
    >> anything in it that is mechanism-specific -- not in the
    >> function name nor any parameters (as in my suggestion).
    >> OM_uint32 gss_is_thread_safe(OM_uint32 *minor_status, OM_uint32
    >> *mt_safe); Cheers, Nico

    Jeffrey> I think you are correct but the problem remains.
    Jeffrey> gss_...... is a reserved name space and I'm not prepared
    Jeffrey> to polute it.  I wish there was a standardized name space
    Jeffrey> allocated for private extensions

I am uncomfortable gating implementation issues on the IETF.  I don't
think that the IETF has yet decided to reserve the gss_* namespace.

--Sam



More information about the krbdev mailing list