r13012: Fix #3421 - it turns out krb5_kt_get_entry() on MIT

does an implicit open/read/close and blows away an
open keytab handle - so make sure we use a new
handle.
Wonderful analysis from Luke <ldeller@xplantechnology.com>
helped fix this.
Jeremy.

1 files changed, 12 insertions, 12 deletions

diff --git a/source/libsmb/clikrb5.c b/source/libsmb/clikrb5.c
index 67e9f539adf..6e87f73df14 100644
--- a/source/libsmb/clikrb5.c
+++ b/source/libsmb/clikrb5.c
@@ -767,7 +767,6 @@ static krb5_enctype get_enctype_from_ap_req(krb5_ap_req *ap_req)
 
 static krb5_error_code
 get_key_from_keytab(krb5_context context,
-		    krb5_keytab keytab,
 		    krb5_const_principal server,
 		    krb5_enctype enctype,
 		    krb5_kvno kvno,
@@ -775,13 +774,18 @@ get_key_from_keytab(krb5_context context,
 {
 	krb5_keytab_entry entry;
 	krb5_error_code ret;
-	krb5_keytab real_keytab;
+	krb5_keytab keytab;
 	char *name = NULL;
 
-	if (keytab == NULL) {
-		krb5_kt_default(context, &real_keytab);
-	} else {
-		real_keytab = keytab;
+	/* We have to open a new keytab handle here, as MIT does
+	   an implicit open/getnext/close on krb5_kt_get_entry. We
+	   may be in the middle of a keytab enumeration when this is
+	   called. JRA. */
+
+	ret = krb5_kt_default(context, &keytab);
+	if (ret) {
+		DEBUG(0,("get_key_from_keytab: failed to open keytab: %s\n", error_message(ret)));
+		return ret;
 	}
 
 	if ( DEBUGLEVEL >= 10 ) {
@@ -792,7 +796,7 @@ get_key_from_keytab(krb5_context context,
 	}
 
 	ret = krb5_kt_get_entry(context,
-				real_keytab,
+				keytab,
 				server,
 				kvno,
 				enctype,
@@ -819,10 +823,7 @@ get_key_from_keytab(krb5_context context,
 	smb_krb5_kt_free_entry(context, &entry);
 	
 out:    
-	if (keytab == NULL) {
-		krb5_kt_close(context, real_keytab);
-	}
-		
+	krb5_kt_close(context, keytab);
 	return ret;
 }
 
@@ -913,7 +914,6 @@ krb5_error_code decode_krb5_ap_req(const krb5_data *code, krb5_ap_req **rep);
 	}
 
 	ret = get_key_from_keytab(context, 
-				  keytab,
 				  server,
 				  enctype,
 				  kvno,