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

[Greg Hudson]

(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.

Checking st_uid seems less safe.  The krb4 code used to do that, and I
believe there are reasons we didn't bring that forward into libkrb5,
although I don't know them.  Certainly there are filesystems which don't
support uids, which are otherwise reasonable to put ccaches in.

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).

>  - second, add a new ccache v4 tag containing a "ccache instance ID",
> to be written by krb5_cc_initialize(), and which should be a value
> that is unlikely to be reused in future calls to krb5_cc_initialize().

This seems reasonable, ignoring the details of generating the instance ID.

>  - third, in the FILE implementation of krb5_cc_next_cred() pread(2)
> the ccache instance ID after locking the ccache and before reading the
> next credential; if the ccache instance ID has changed, then re-read
> the ccache header and reset the cursor to point to the current first
> credential, then continue.

As long as we have a portability shim for systems without pread, this
also seems reasonable.