[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