Re: documentation vs specification

On Mon, 2011-10-03 at 15:21 -0500, Nico Williams wrote:
> On Mon, Oct 3, 2011 at 2:50 PM,  <[email protected]> wrote:


> > lock()+truncate()/seek()+write()+unlock() is more complicated and can
> > lead to an inconsistent reader state. Locking is also a can of worms
> > itself (what if the writer stalls?).
> 
> Indeed.  I recommend against this.

Nonsense.  Holding an appropriate file lock on a ccache while reading or
updating it is the right way to handle the shared-access problem; it's
what file locking is _for_.  I've seen several fairly complex proposals
here for different ways to solve this problem, none of which is actually
better than just doing what the existing implementations already do,
which is to keep the file open only while they are accessing it and
acquire an appropriate file lock while doing so.


The original point of this thread was to discuss a deficiency in kstart,
which does not avoid a situation in which applications using a ccache
may see an _empty_ cache.  The best solution for that problem is for
kstart to obtain new initial credentials into, say, a MEMORY cache, then
truncate the managed ccache and copy the new credentials in, all under
the same lock.

Unfortunately, the current API doesn't seem to provide a way to do that.
This is a failing in the API, not a flaw in the established access
pattern for file ccaches.  The right fix is to fix the API.  Failing
that, it would be appropriate for a program like kstart to write the new
credentials into a new file cache, then move it into place.

-- Jeff