From nobody@FreeBSD.org  Fri Oct 21 16:45:02 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B051F106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 21 Oct 2011 16:45:02 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 80A4B8FC0C
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 21 Oct 2011 16:45:02 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p9LGj1eb069815
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 21 Oct 2011 16:45:01 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id p9LGj148069810;
	Fri, 21 Oct 2011 16:45:01 GMT
	(envelope-from nobody)
Message-Id: <201110211645.p9LGj148069810@red.freebsd.org>
Date: Fri, 21 Oct 2011 16:45:01 GMT
From: Harry Coin <hcoin@quietfountain.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Gssapi/krb5 memory leak, massive krb5.conf re-read slowness
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         161884
>Category:       kern
>Synopsis:       [kerberos] [patch] gssapi/krb5 memory leak, massive krb5.conf re-read slowness
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Oct 21 16:50:07 UTC 2011
>Closed-Date:    Mon Oct 24 07:38:16 UTC 2011
>Last-Modified:  Mon Oct 24 07:38:16 UTC 2011
>Originator:     Harry Coin
>Release:        8Stable
>Organization:
Quiet Fountain LLC
>Environment:
amd64
>Description:
Notice in
http://svnweb.freebsd.org/base/head/kerberos5/lib/libgssapi_krb5/pname_to_uid.c?revision=181344&view=markup

and elsewhere where gssapi meets kerberos we see gssapi mechanism procedures
which are entered frequently.  Such as every time a user connects to an NFS
share, every time SASL/gssapi/kerberos via SASL to get an LDAP lookup happens.

These procedures have something like this:

GSSAPI_KRB5_INIT(&context)
. processing..

and then exit without freeing the kerberos context.  That context has
in it many memory allocations for extensive internal structures, none
of which are released when the subroutine is simply exited before
freeing it.

Worse than that by many standards:  the business of creating a kerberos
context involves reading and parsing the krb5.conf file.. which in turn
makes references to potentially a gracious plenty other files.   This
gssapi code involving kerberos should create the context one time when
the process begins, then keep it open and re-use the context straight
on until the process ends.   Frequently building and discarding the
context every time credentials have to be checked between a principal
and a local user name is incredibly wasteful of time and disk traffic.

>How-To-Repeat:
Set up an nfs export using -sec=krb5xx.  Watch memory use go up in gssd for example.

>Fix:

OM_uint32
_gsskrb5_pname_to_uid(OM_uint32 *minor_status, const gss_name_t pname,
    const gss_OID mech, uid_t *uidp)
..

	kret = krb5_aname_to_localname(context, name, sizeof(lname), lname);
 	//printf("Kret %d lname %s\n",kret,lname);
+	krb5_free_context(context);
	if (kret) {
		*minor_status = kret;
		return (GSS_S_FAILURE);
	}


This just fixes the memory leak, it doesn't fix the waste involved in
building a whole context and throwing it away every time gssapi needs
to check what principal goes with which user.   Note also the previous
bug report increasing the password buffer size from 128 to 1024, since
long prinicpal names, long passwords, long home directories and long
gecos info often extends beyond 128 bytes so causing nfs shares to be
denied access owing to wrongful authentication failures.


>Release-Note:
>Audit-Trail:

From: Harry Coin <harrycoin@aol.com>
To: bug-followup@FreeBSD.org, hcoin@quietfountain.com
Cc:  
Subject: Re: kern/161884: Gssapi/krb5 memory leak, massive krb5.conf re-read
 slowness
Date: Sun, 23 Oct 2011 21:31:21 -0500

 Withdrawn entirely as I found the the static 'create_key' mechanism in 
 the odd do { } while(0) construction in the GSS... define.
 
 This can be closed, it was an error to have filed it.
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Mon Oct 24 07:38:05 UTC 2011 
State-Changed-Why:  
Closed at submitter's request. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=161884 
>Unformatted:
