Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.507 (Entity 5.507)
RT-Send-CC:
X-RT-Original-Encoding: iso-8859-1
Content-Length: 1564

In IRC Nico suggested a fifth option, which I think is a little 
outside the box but still worth considering.  My interpretation is:

5. On krb5_cc_initialize(), do nothing externally visible (or at 
least no more visible than creating a temporary file).  When the 
first non-config credential entry is stored, then atomically replace 
the ccache as it is visible to other handles.

There are two caveats to this approach:

A. For this approach to work, the first non-config credential entry 
to be stored must be the TGT, or the sole service ticket for non-TGT 
ccaches, and  important config entries must be written before that 
credential is written.

This property is likely already true for creating uses like kinit and 
gss_acquire_cred_with_password().  But when the cache is created by a 
copy operation, as it is with gss_store_cred_into(), this property 
relies on iteration (from the source ccache) preserving order, at 
least loosely.  Our implementation of the MEMORY ccache type 
currently reverses order during iteration; that would need to be 
changed, and other ccache types such as KEYRING would need to be 
inventoried to determine if they preserve order.

B. This approach does requires the cache to be created via a single 
handle, up through storing the first non-cred entry.  For example, a 
caller who creates a cache, initializes it, closes it, and then 
passes the name to some other agent to fill in credentials will no 
longer work.  A review of known Kerberos applications like kstart 
would be indicated to make sure no one does this.