FILE ccache corruption, possible fix

[Nico Williams]

I won't recap the IRC discussion from earlier today.  Suffice it to say
that there is a race in krb5_fcc_close_file() between the unlock and the
close(2) of the ccache: the close(2) can drop locks acquired by other
threads between the dropping of locks and the closing of the fildes in
this thread (a writer).

I think the most elegant fix is as follows (note: not yet tested):

 - Don't lock the ccache to read.  If an entry appears to be truncated
   (i.e., EOF too soon), ignore it.  This may require returning a bogus
   ccache entry from krb5_cc_next_cred() in order to keep backwards
   compatibility.

   I.e., assume creds are only appended or otherwise, if overwritten,
   that they are overwritten atomically with equal-sized entries, and
   only to delete them.  (The part about overwrites is tricky, but don't
   focus on that for now; if need be assume that ccaches are
   append-only.)

 - Don't unlock the ccache when writing, just close(2) the file
   descriptor.  This requires knowing in krb5_fcc_close_file() whether
   we're using POSIX file locking.

This doesn't require waiting for "private locks" (a proposed variant of
POSIX file locking that addresses the POSIX file locking drop-locks-on-
first-close insanity) and is fairly simple.

Earlier I'd proposed borrowing ideas from SQLite3, but I think the above
is much simpler and safer.

Nico
--