Reducing FILE ccache race conditions: please allocate new ccache v4 tag

[Roland C. Dowdeswell]

On Wed, Aug 14, 2013 at 12:11:58PM -0400, Greg Hudson wrote:
>

> (Some of this is repeating IRC discussion.)
> 
> On 08/09/2013 12:37 PM, Nico Williams wrote:
> >  - first, regarding 1777 mode tmp dirs, use O_NOFOLLOW and check that
> > st_uid matches EUID; there are things that can be done in the absence
> > of O_NOFOLLOW too;
> 
> Using O_NOFOLLOW where available, for initialization, seems reasonable
> and safe.  We already unlink() caches before opening them for
> initialization, so nobody could be relying on initialize following symlinks.

The unlink(2), however, is problematic as it makes it difficult to
use kinit(1) with persistent jobs as the ccache sometimes isn't
there.  This is the cause of some of the races that we observed.

> On IRC, Nico suggested there might be more complicated changes to do
> initialization better, such as creating a temporary file and renaming it
> into place after writing the header.  I believe that wouldn't work on
> Windows, but on Unix systems would eliminate the window where a
> concurrent reader sees a completely empty cache file (not yet locked, no
> header written yet).

Fundamentally, what we need to eventually achieve is an API where
it is possible to atomically create a valid working ccache over an
existing valid working ccache with there being no invalid or credless
ccache at any point in time.  With the current APIs, this is not
possible as the ccache is unlocked between the calls to create it
and the calls to populate it meaning that no matter how well we
do, there is an opportunity for a reader to open a ccache which
has no creds in it.

Some time ago, Nico and I discussed the idea of making krb5_cc_move()
work in a proper atomic way which would allow one to, e.g. create
a MEMORY: ccache and then use krb5_cc_move() to install it into
the file system in a single (and properly locked) step.  Perhaps
we should consider discussing this further after the current
conversation has concluded.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/