How to prevent very very large ccaches?

Nicolas Williams Nicolas.Williams at ubsw.com
Tue Jun 18 16:38:20 EDT 2002


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
       KRSH connection. If you have many thousands of hosts this becomes
       a big problem. The problem is that each krsh will lock/unlock the
       ccache once for each entry in the ccache while searching for a
       service ticket for the destination host.

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.

Comments? Silence -> I'll send a bug report including this patch.

Nico

Index: LOCAL-122.13/lib/krb5/ccache/cc_retr.c
--- LOCAL-122.13/lib/krb5/ccache/cc_retr.c Wed, 14 Mar 2001 14:20:32 -0500
+++ LOCAL-122.13(w)/lib/krb5/ccache/cc_retr.c Tue, 18 Jun 2002 15:57:43 -0400
@@ -193,6 +193,27 @@
      if (kret != KRB5_OK)
 	  return kret;
 
+     /*
+      * krb5_cc_start_seq_get() leaves the ccache open and locked, but
+      * if we don't unset the KRB5_TC_OPENCLOSE ccache flag then
+      * krb5_cc_next_cred() will open/lock/close the ccache for every
+      * entry it iterates over. If several processes are doing a
+      * krb5_cc_retrieve_cred_seq() (or krb5_get_credential()) in
+      * parallel with the same ccache and the ccache is very large, then
+      * the context switch / lock contention overhead in searching the
+      * ccache will grow very large indeed. Think of doing a krsh to
+      * each of 1,000 hosts with, say, 30 krsh client processes running
+      * at any time.
+      * 
+      * The KRB5_TC_OPENCLOSE ccache flag has to be set again before we
+      * call krb5_cc_end_seq_get() though. Since there is no
+      * krb5_cc_get_flags() we have to assume that KRB5_TC_OPENCLOSE is
+      * always set except when explicitly unset.
+      *
+      * Nicolas.Williams at ubsw.com
+      */
+     (void) krb5_cc_set_flags(context, id, 0);
+
      while ((kret = krb5_cc_next_cred(context, id, &cursor, &fetchcreds)) == KRB5_OK) {
 	 if (((set(KRB5_TC_MATCH_SRV_NAMEONLY) &&
 		   srvname_match(context, mcreds, &fetchcreds)) ||
@@ -236,6 +257,7 @@
 		      continue;
 		  }
 	      } else {
+		  (void) krb5_cc_set_flags(context, id, KRB5_TC_OPENCLOSE);
 		  krb5_cc_end_seq_get(context, id, &cursor);
 		  *creds = fetchcreds;
 		  return KRB5_OK;
@@ -247,6 +269,7 @@
      }
 
      /* If we get here, a match wasn't found */
+     (void) krb5_cc_set_flags(context, id, KRB5_TC_OPENCLOSE);
      krb5_cc_end_seq_get(context, id, &cursor);
      if (have_creds) {
 	 *creds = best.creds;
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.




More information about the Kerberos mailing list