Thread-safety in Kerberos libs
raeburn at MIT.EDU
Sat Dec 29 05:09:07 EST 2007
On Dec 28, 2007, at 21:55, Xiaoshan Zuo wrote:
> I am working on adding Kerberos authentication to a multi-threaded
> application. The libraries I am going to use are libkrb4.s0.2 and
> libgssapi_krb5.so.2. The exact functions I am going to use in a
> multi-threaded context are:
> I am trying to figure out whether those functions are thread-safe. In
> the doc/threads.txt file, it says that:
> "Any use of krb5_context must be confined to one thread at a time by
> the application code."
It should say something along the lines of, "Any use of a given
krb5_context object...." Using distinct krb5_context objects
simultaneously in different threads should be fine.
Also, that doesn't quite apply to the GSS library; any uses in there
of a global krb5_context should be protected by locks. Generally,
any simple read-only object like an input buffer or OID can be shared
across threads; GSS credentials can be shared; GSS security contexts
cannot. I'd have to go digging around to figure out the rest.
Note that thread safety is not part of the GSSAPI specification. In
another implementation, it may not be safe to perform any GSSAPI
operations simultaneously in two threads, even simple ones on
seemingly unrelated objects.
You also mention libkrb4, but not what functions might be used in
multithreaded operation. Be aware that not only are many of the
libkrb4 functions not thread-safe (and unlikely to ever be made
safe), but the library also maintains internal state across calls in
one or two places, such that a sequence of calls in two threads,
fully serialized but relating to two different authentication
contexts, could give incorrect results. Like too many things, this
isn't well documented. :-( Since our eventual plan is to eliminate
krb4, I doubt this will get fixed.
> I also searched the email archive, there are multiple threads on this
> subject. In those threads, people blamed some functions in C
> library for
> causing thread-safe problem, there was no mention of krb5_context.
> Do we
> know whether it is just C library or Kerberos library is not thread-
> by itself?
We've tried to make accesses to certain types of objects (like ccache
and keytab objects) thread-safe by adding locking. Simple data
structures included in krb5.h, like krb5_data and principal names,
can't have mutexes added without changing the API that we've
committed to maintaining for now, so uses of them can't be made
thread-safe, though read-only uses (if we actually documented which
those are) can be done simultaneously. Any global state in the krb5
library (except for a couple of exported global variables that are
part of that API) should be protected by mutexes. Anything dealing
with global state like signals and terminal I/O are going to get
messy in multithreaded code.
Because of some of these things, it's never going to be the case that
two threads can do absolutely anything they want in the krb5 library
without interfering with each other. If both try to prompt for
passwords, for example, things will probably get confused. But I
believe we've done a fairly good job of making thread-safe everything
we intended to; any remaining issues (including the glaring lack of
current, clear, specific documentation on this issue) are bugs. (I
see the latest release of valgrind has the helgrind tool enabled
again; we should use that and run some tests, it may well find
problems we've overlooked.)
We do rely on stuff in other libraries that may or may not be thread-
safe. Some implementations of getaddrinfo, for example, are not
thread-safe, and that's not something you can really test for in a
configure script. Some systems are missing thread-safe "_r" versions
of various C library routines (e.g., getpwnam, gmtime) and thus wind
up using shared static storage; that, we check for at configure time
and issue warning messages.
Please do let us know if you encounter any problems relating to
thread safety in the GSSAPI or krb5 libraries.
More information about the krbdev