[4963] in Kerberos

home help back first fref pref prev next nref lref last post

MIT krb5 B4-3

daemon@ATHENA.MIT.EDU (Edwin Phillips)
Wed Apr 12 19:16:19 1995

To: kerberos@MIT.EDU
Date: 12 Apr 1995 18:54:15 -0400
From: flaregun@strauss.udel.edu (Edwin Phillips)

	I recently retrieved and built MIT krb5 B4-3 and all has gone
relatively well (even under Solaris2.4).  We've been working toward the use
of Kerberos for network printing and Unix accounting for years now, using the
Sandia Kerberos5 distribution that we got years ago.  All has been fine until
I recently started using libkrb5.a for client-server authentication for a Unix
accounting application.  I soon found that there are many problems with the
Sandia port of krb5, mostly memory leak related.
	Here are some of my findings with MIT krb5.

	In lib/krb5/keytab/file/ktf_get_en.c, there are some logic problems
which make it impossible to get any keys from a srvtab (at least via
get_in_tkt_with_skey()).

	I've only tracked down a couple so far, but there is/are substantial
memory leaks in lib/krb5/rcache/rc_dfl.c (line 400), such that an application
which calls recvauth()/sendauth() 1500 times grows from 1.5M to 7.5M, even
after free()ing up all the return values for creds, authenticator, etc.
	Other possible leaks seem to be in lib/krb5/keytab/file/ktf_resolv.c,
lines 41, 45 and 50.
	
	There are some minor installation problems (headers don't get
installed with `make install'), and I don't really understand why kadmind
crashes if you don't put in "that fix", but it does.

	Sorry if this is incoherent (I'm being rushed).

	Can anyone help with these problems?  Are there any patches?  Is
Theodore Ts'o still leading the project?  (Last I remember he was working on
tty/serial stuff for Linux.)

Here's a patch:

*** lib/krb5/keytab/file/ktf_get_en.c_orig	Wed Apr 12 12:52:33 1995
--- lib/krb5/keytab/file/ktf_get_en.c	Wed Apr 12 14:28:17 1995
***************
*** 67,79 ****
  				cur_entry = new_entry;
  			}
  		} else {
! 			cur_entry = new_entry;
! 			break;
  		}
  	} else {
  		krb5_kt_free_entry(&new_entry);
  	}
      }
      if (kerror) {
  	if (kerror == KRB5_KT_END)
  	    kerror = KRB5_KT_NOTFOUND;
--- 67,95 ----
  				cur_entry = new_entry;
  			}
  		} else {
! 			if (kvno == new_entry.vno) {
! 				krb5_kt_free_entry(&cur_entry);
! 				cur_entry = new_entry;
! 				break;
! 			}
! 			else
! 				krb5_kt_free_entry(&new_entry);
  		}
  	} else {
  		krb5_kt_free_entry(&new_entry);
  	}
      }
+ 
+     if ((kvno == IGNORE_VNO) && (cur_entry.vno > 0))
+     {
+ 	if ((kerror = krb5_ktfileint_close(id)) != 0) {
+ 	    krb5_kt_free_entry(&cur_entry);
+ 	    return kerror;
+ 	}
+ 	*entry = cur_entry;
+ 	return 0;
+     }
+ 
      if (kerror) {
  	if (kerror == KRB5_KT_END)
  	    kerror = KRB5_KT_NOTFOUND;
-- 
/****************************************************************************/
/* Ed Phillips  flaregun@udel.edu              University of Delaware       */
/* Jr Systems Programmer  (302) 831-6082    IT/Network and Systems Services */
/****************************************************************************/

home help back first fref pref prev next nref lref last post