From nobody@FreeBSD.org Fri Oct 21 16:45:02 2011 Return-Path: Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B051F106566B for ; 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 ; 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 ; 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 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 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: