Concurrency issue between krb5_cc_retrieve_cred and krb5_cc_store_cred
kstemen at likewise.com
Tue May 5 13:07:19 EDT 2009
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
More information about the krbdev