[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ticket cache file

On Mar 26, 2008, at 3:34 , Harald Barth wrote:
>> FILE credential cache implements locking. However I just noticed  
>> that destroy doesn't implement locking, just fixed that.
> So either that code does not work as expected or we have to find
> what else it is that garbles our users ticket files from time to time.

The code I see attempts to fcntl() lock 0 bytes at offset 0.  This is  
translated to lock all bytes of the file; some OSes may treat this as  
a whole-file lock a la flock() (cf. Darwin/Mac OS X) but this is not  
reliable.  If the OS does not promote it to a whole-file lock,  
multiple processes attempting to extend the file will not encounter  
locks, as I read this.

I would suggest locking with len 2GB-1 in this case; POSIX compliant  
systems should permit this.  (Of course this probably needs to be  
verified, but I have no idea what to do if it fails and there is no  
flock() or locking() to fall back to.

> Btw, the library is not very robust when encountering a ccache file
> containing a garbled service ticket in the middle. The right way would
> be to just reissue the service ticket from the still intact tgt at the

Without caching it afterward, I hope (which probably requires a  
"ccache invalid" state) --- otherwise if the ccache is garbled, this  
will just make things worse.

brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH