Re: documentation vs specification

On Mon, Oct 03, 2011 at 05:12:15PM -0400, Jeffrey Hutzelman 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?).
> 
> 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

Even though locking is a "tool for the very purpose" it is not the only
tool for the purpose and it comes with its own inherent problems.

One may wish to avoid them.

Simple recreating and (atomic) replacing the whole file can lose some of
the updates due to races but it keeps data consistent (even if potentially
incomplete/stale) at all times. Completeness can be checked after an
update and the update can be retried if a race has been detected. Not
exactly efficient but I doubt we would hit any contention/performance
issues.

Another (hypothetical but) nice lock-free approach might be possible if
a ccache could be a directory with multiple files instead of a single one,
then e.g. a maildir-like structure would suit very well.

It would be actually a correct use of a Posix-like file system
for robust and lock free data sharing.

> ccaches.  The right fix is to fix the API.  Failing

I guess it would be helpful to make certain changes to the API.

We seem to agree about ccaches being used for interprocess communication.

Note how the processes find the relevant ccaches. Normally they are using
the default (or pointed to by KRB5CCNAME) ccache. This implies "_one_ ccache
per process" and makes it e.g. cumbersome to start several ssh sessions
to different hosts demanding credentials for different realms.

It is possible to work around by using scripts for creating (and
cleaning?..) new ccache files and running kinit and then ssh against
them and so on. This is some extra work and complication (among others
extra complexity is bad for security). But why in the first hand?

There seems to be no good reason to bind a ccache to a _principal_. A
local identity (like uid in Unix) may need to possess a lot of credentials
for different realms and principals and there is no point in isolating
them from each other as long as it is the same local identity which is
using them. So a single ccache should be able to handle all credentials
of a local identity (uid in Unix).

IOW, a possibility to use multiple ccaches per uid may be fine but the
coersion by the API to do so is bad.

Regards,
Rune