[krbdev.mit.edu #9178] [Comment] krb5_cc_set_config() fails to overwrite existing entries and creates duplicate credential objects

[Greg Hudson via RT]

http://kerborg-prod-app-1.mit.edu/rt/Ticket/Display.html?id=9178
This is a comment.  It is not sent to the Requestor(s):

The referenced commit  c0a51fe0c8051e27c6cee4f4f0c705356a715e1e uses as
justification that krb5_cc_store_cred() will remove duplicates, but a few
years later commit 7783054742ddd807f7b2f7157d6ed81b7fb614eb removed that
behavior.

I think commit 729896467e3c77904666019d6cbbda583ae49b95 also may have resulted
in poor ccache behavior around credential expiration time, setting a new
refresh time on every gss_acquire_cred() call within 30 seconds of cred
expiration, even if one is already set.  (If refreshing succeeds the ccache is
wiped, so the problem only manifests when we can't refresh the cache.  But it
looks like we call kg_cred_time_to_refresh() via maybe_get_initial_cred() on
every krb5 gss_acquire_cred() initiator call, even if no keytab is present.) 
Even if the krb5_cc_store_cred() calls were semantically correct we would
create large FILE ccaches full of deleted config entries.

There's a reasonable argument that refresh_time isn't a good match for
krb5_cc_set_config(), given the append-only nature of the most common ccache
type.  Unfortunately, I don't think there is an alternative mechanism to
prevent AS-REQ storms when we try to refresh a ccache from the keytab and
fail.