How to prevent very very large ccaches?

Ken Raeburn raeburn at MIT.EDU
Tue Jun 18 17:41:22 EDT 2002

"Nicolas Williams" <Nicolas.Williams at> writes:

> Recap: "krsh host date" for 1,000 hosts, 20 at a time; by the time the
>        ccache grows to half its eventual size the overhead of searching
>        through the ccache swamps the overhead of the TGS exchange and

Wow.  I knew we had some bogus stuff in some of our I/O code, but
didn't realize it was so serious.

> This patch fixes the problem. It unsets the KRB5_TC_OPENCLOSE ccache
> flag during cred retrieval, thus causing each krsh/ssh/ftp/whatever
> process to run the ccache cred search to completion with one
> open/lock/close cycle, rather than one cycle per-ccache entry.
> Alternatively lib/krb5/krb/get_cred.c could be patched to bracket the
> call to the cred retrieval function with calls to krb5_cc_get_flags() to
> unset, then set the KRB5_TC_OPENCLOSE flag. Maybe. I'm not sure that
> krb5_cc_start_seq_get() would work correctly if the ccache it's called
> with is closed and has the KRB5_TC_OPENCLOSE flag unset.

If the ccache is passed in, I think the flag state should be restored
at the end to the way the caller might have set it.  But I think
cc_retr.c is the right place for temporarily overriding the one flag.

So is performance acceptable at 1000 entries now, or should we look at
a db2 ccache format? :-)


More information about the Kerberos mailing list