Concurrency issue between krb5_cc_retrieve_cred and krb5_cc_store_cred

[Kyle Stemen]

Sam Hartman wrote:
> Do you have any thoughts on the fix?
> Approaches to try for me seem to include:
>
> * Lock, reopen rw, unlock  if we get EBADF
>   

So the contract would be that when KRB5_TC_OPENCLOSE is set, the file is 
left opened read only, until krb5_fcc_store is called. From then on, the 
file is left open in rw mode.

I think this is an acceptable solution, but personally, would prefer if 
a flag was used to track whether the file is in rw mode instead of 
having to catch the write failure.

> * Clear the openclose flag and try again if we get EBADF
> * Lock around the entire sequential operation in retrieve 
>   
I dislike these options because KRB5_TC_OPENCLOSE is exposed in the 
public API. If krb5_fcc_store clears the flag, it would mean the 
function has an unexpected side effect. If you lock around the retrieve, 
krb5_fcc_store will still fail if openclose is set through the public API.

> One factor to consider is difference between Windows and Unix locking semantics.
>