Concurrency issue between krb5_cc_retrieve_cred and krb5_cc_store_cred

[Kyle Stemen]

Sorry, I just realized I had it backwards, I meant when 
KRB5_TC_OPENCLOSE is unset.

Kyle Stemen wrote:
> 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.
>>   
>
>