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 ubsw.com> 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? :-)
Ken
More information about the Kerberos
mailing list