Concurrency issue between krb5_cc_retrieve_cred and krb5_cc_store_cred

[Kyle Stemen]

The file descriptor for file based credentials caches is opened in
O_RDONLY or O_RDWR depending on the operation. krb5_cc_store_cred
requires the file to be opened in O_RDWR mode.

The file credential cache has a flag, KRB5_TC_OPENCLOSE, that causes the
credentials cache to be reopened for every element operation. As an
optimization, krb5_cc_retrieve_cred_seq turns off that flag for the
duration of the function:
static krb5_error_code
krb5_cc_retrieve_cred_seq (krb5_context context, krb5_ccache id,
			   krb5_flags whichfields, krb5_creds *mcreds,
			   krb5_creds *creds, int nktypes, krb5_enctype *ktypes)
{
...
     if (oflags & KRB5_TC_OPENCLOSE)
	 (void) krb5_cc_set_flags(context, id, oflags & ~KRB5_TC_OPENCLOSE);
...
     if (oflags & KRB5_TC_OPENCLOSE)
	 krb5_cc_set_flags(context, id, oflags);
}


When krb5_fcc_set_flags turns off KRB5_TC_OPENCLOSE, it opens the file
in read only mode. If krb5_cc_store_cred is called at that point, it
will reuse the existing read only file descriptor. When
krb5_cc_store_cred tries to write, it will get EBADF. That error will
then get translated to  KRB5_FCC_INTERNAL. So krb5_cc_store_cred only
works when KRB5_TC_OPENCLOSE is on (so the file can be opened in read
write mode). 

krb5_cc_retrieve_cred_seq does not lock the cache file for the entire
operation (only for each individual seek and read). This means there is
a race condition between krb5_cc_store_cred and krb5_cc_retrieve_cred.
The attached program illustrates the failure. On my test machine, it
fails on loop 500 or so.

I am using Kerberos 1.6.3, but I don't see anything that would fix this
in the krb5-1-7 branch of your svn.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krb5_concurrency.c
Type: text/x-csrc
Size: 2423 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090504/13402bc3/attachment.bin