How is an application supposed to know if a Kerberos library isthread safe?
Nicolas.Williams at sun.com
Mon Dec 20 15:56:22 EST 2004
On Mon, Dec 20, 2004 at 03:31:45PM -0500, Jeffrey Altman wrote:
> 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);
> I think you are correct but the problem remains. gss_...... is a
> reserved name space and I'm not prepared to polute it. I wish there
> was a standardized name space allocated for private extensions
And why would "gss_krb5_*" not pollute it either?
In my I-D on GSS namespaces I will include directions for an IANA
registry for the GSS namespaces, registration procedures and namespace
allocation policies setting aside portions of some such namespaces for
mechanism-specific extensions and other portions for platform- or
implementation-specific extensions. Grandfathering of existing
non-standards-track namespace usage could be done, perhaps with such
entries labeled "informational."
Of course, namespace allocation policies require careful thought -- use
of underscores, for example, for indicating that some name is mech-
specific may be a bad idea if there's any languages where there is no
appropriate mapping of the underscores in generic names.
More information about the krbdev