Re: Wishlist: credential file update/access collision avoidance?

On Sun, Oct 02, 2011 at 05:57:25PM -0500, Nico Williams wrote:
> IIRC Solaris' krb5_cc_initialize() rename a new file into place after
> setting ownership/perms to match the old one, if there was an old one.
>  I don't recall the details.
> 
> That's what should be done here.

I guess it is hard anyway to be "exactly" correct and avoid races,
without placing/assuming additional constraints on the setup.

> Oh, and on Unix systems, ccaches should only ever be stored in tmpfs
> filesystems, so, yes, you can expect POSIX semantics.

Hmm, I doubt two things, that all Unix systems have/use tmpfs :)
and that documentations explains in depths how the credentials caches
are to be handled. Without these prerequisites a lot of systems
end up being setup differently.

Actually, file credentials caches are rather a hack than a consequent
solution. Trying to make them "work well" is not necessarily an effort
spent well.

It is the fact that the file service in *nix provides both authentication
and authorization and a rudimentary form of shared access which lets it
to be used as "a communication protocol". For keytabs this mostly fits
the bill - but hardly for ccaches.

It looks like a dedicated service (though preferably not in the kernel
like AFS does, a user space daemon is more general and flexible) would
be the only reliable way to share time-limited credentials between
independent processes. Then the interoperability standard should be
the protocol of the service, nothing else (e.g. not the format of the
file ccaches).

Otherwise we should at least specify which properties are assumed
from the underlying file system (among others, access control)
and also the exact "protocol" for updates, say a rename().
Otherwise different implementations will be unable to cooperate reliably.

The current situation is that a lot of installations do not operate
reliably. Sigh. May be it is alright? :)

Regards,
Rune