Thread-safety in Kerberos libs
raeburn at MIT.EDU
Sat Dec 29 15:19:39 EST 2007
On Dec 29, 2007, at 14:21, Xiaoshan Zuo wrote:
> Our requirement comes down to the thread-safety of the code in
> xdr_rpc_gss_wrap_data() function:
I don't see anything glaring there that would make it unsafe for a
multithreaded environment, if "ctx" is not shared, though if
debugging is enabled the log_debug or log_status output from multiple
threads could get interleaved; but note that we haven't analyzed our
version of the rpc library for thread safety. And a spot check does
find in clnt_perror.c a routine get_buf that provides a buffer to the
caller using an unprotected global variable, rather than using per-
thread data (which is the approach we've used for this sort of thing
in the past, if you feel like submitting a patch).
> And similar function xdr_rpc_gss_wrap_data(). gss_get_mic() and
> gss_wrap() can be called at the same time, and any one of them can be
> called by more than one threads simultaneously.
That part should be okay, as long as the security contexts aren't
> Is a global krb5_context used in the libraries? I guess you mean the
> krb5_context created by calling program.
There were at some times; I'm not sure if we've eliminated them all.
If there are, they should be protected by mutexes.
When passing a krb5_context from the application, you need to make
sure yourself that it's only in use from one thread at a time.
> The thing we care about is: can two threads call krb5 library to do
> integrity check and encryption/decryption on input buffers at the same
> time with the same krb5 context. Since those operations don't
> change any
> security context which is established at context creation, they should
> be thread-safe.
The krb5 context includes cached information from the config file,
which includes information on supported encryption types and such.
The config file data may be updated if it hasn't been read before, or
if the config files have changed; other fields cache the results of
parsing certain of the config file entries. So, yes, it's possible
for the context to be changed by many of the calls into the krb5
library, and it's not safe for a krb5_context to be used in more than
one thread. You should create one per thread, or create a shared
pool of them, or something like that.
> Do you see there are any thread-safety issues on those operations? In
> gss_krb5int_make_seal_token_v3() from file k5sealv3.c, ctx-
> >seq_send is
> modified and used without locking, is this a problem?
That's the GSSAPI security context, and is also not protected against
use in multiple threads. It maintains such state as message sequence
numbers. If you want to use it in multiple threads, locking will be
More information about the krbdev