Thread-safety in Kerberos libs

[Ken Raeburn]

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  
shared.

> 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  
required.

Ken