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

[Nico Williams]

So specific enhancements I want:

 - ccache v4 instance ID tag (opaque, typically random instance ID),
with krb5_cc_get_next() checking it between locking the ccache and
reading the next cred, rewinding if the instance ID changed;

 - an option to iniitialize and hold a lock indefinitely, until all cc
configs and TGTs are written;

   (this could be done heuristically, since programs that
krb5_cc_initialize() generally store some cred or otherwise
krb5_cc_close(); perhaps the actual initialization should be deferred,
storing everything in MEMORY until the app has krb5_cc_store_cred()'ed
a TGT, *then* atomically re-initialize and write that to the FILE
ccache)

 - implement the hint to krb5_cc_new_unique() as the name of a ccahce
or a directory, so that new_unique() can create the temp file in the
same filesystem as the name it will eventually be krb5_cc_moved() to;

 - always truncate (with locks held) at initialize time instead of
unlik.  this requires two opens: first an open with O_RDWR | O_CREAT
to make sure we have an fd to lock, then open with O_WRDONLY | O_TRUNC
to truncate (or else ftruncate());

 - better actual (O_NOFOLLOW) and heuristic (for older OSes) support
for defeating symlink attacks in /tmp, including some st_uid checks
(perhaps just st_uid == getuid() || st_uid == geteuid().

BTW, I have patches for Heimdal that implement krb5_cc_remove_cred()
for FILE ccaches by overwriting the old cred with the same cred -at
the same offset-, where the new cred has a) endtime == 1, b) if the
cred was a cc config cred then the realm of the service principal is
changed from X-CACHECONF to X-RMED-CONF (since cc configs are looked
up without KRB5_TC_MATCH_TIMES and their endtime is set to 0 in MIT).

No more racing please...

Nico
--