From root@ns-dev.rutgers.edu Tue Jan 13 15:20:42 1998
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id PAA06983 for <bugs@RT-11.MIT.EDU>; Tue, 13 Jan 1998 15:20:34 -0500
Received: from ns-dev.rutgers.edu by MIT.EDU with SMTP
id AA19324; Tue, 13 Jan 98 15:20:35 EST
Received: (from root@localhost)
by ns-dev.rutgers.edu (8.8.5/8.8.5) id PAA17673;
Tue, 13 Jan 1998 15:20:17 -0500 (EST)
Message-Id: <199801132020.PAA17673@ns-dev.rutgers.edu>
Date: Tue, 13 Jan 1998 15:20:17 -0500 (EST)
From: hedrick@nbcs.rutgers.edu
Reply-To: hedrick@nbcs.rutgers.edu
To: krb5-bugs@MIT.EDU
Subject: kadmind fast file descriptor leak
X-Send-Pr-Version: 3.99
System: SunOS ns-dev.rutgers.edu 5.5.1 Generic sun4m sparc SUNW,SPARCstation-20
Architecture: sun4
Kadmind is leaking file descriptors. After a few hours, lsof shows
lots of fd's open on /usr/tmp/rc_kadmin_0.
I suspect that the replay cache is not working properly. The rcache
code doesn't seem to be designed to have multiple contexts working
with the same replay cache file name. In such a case I believe
invalid things will happen.
Change your password 64 times.
The RPC mechanism is calling _svcauth_gssapi, krb5_gss_accept_sec_context,
krb5_rd_req, krb5_get_server_rcache. Krb5_gss_accept_sec_context
creates a new auth context. Since its rcache field is NULL,
krb5_rd_req calls krb5_get_server_rcache to create a new krb5_rcache.
The end result is a new rcache for each authenticator. This appears
to be invalid (though without real documentation for the library
calls, it's hard to be sure what is and isn't valid).
I propose to chance krb5_get_server_rcache to maintain a global
krb5_rcache. The first time it is called, the existing code
would be used to create one. All later times, the same
krb5_rcache would be returned.
Responsible-Changed-From-To: bjaspan->tlyu
Responsible-Changed-By: tlyu
Responsible-Changed-When: Thu Jan 22 23:42:34 1998
Responsible-Changed-Why:
Mine!
State-Changed-From-To: open-feedback
State-Changed-By: tlyu
State-Changed-When: Thu Jan 22 23:42:48 1998
State-Changed-Why:
Should be fixed by patches to deal with [370]
From: Tom Yu <tlyu@MIT.EDU>
To: hedrick@nbcs.rutgers.edu
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/526: kadmind is leaking file descriptors
Date: Thu, 22 Jan 1998 23:48:59 -0500
The actual problem comes from the gssapi library calling krb5_rd_req
with an auth_context but without freeing the resultant rcache. If a
NULL auth_context were passed in, or if the rcache were then freed,
this wouldn't be a problem. Fortunately, another solution has been
provided by jik, who filed another bug report with fixes that would
allow the gssapi library to maintain a single rcache per server-side
gssapi credentials, resulting in a speedup as well as getting rid of
the problem with file descriptors leaking. I was able to connect
repeatedly to a kadmind in a tight loop without running out of file
descriptors. Please check a recent krb5-current snapshot (available
from athena-dist.mit.edu:/pub/kerberos) and tell me if the problem has
been fixed in our current sources.
---Tom
From: "Charles Hedrick" <hedrick@geneva.rutgers.edu>
To: hedrick@nbcs.rutgers.edu, tlyu@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/526: kadmind is leaking file descriptors
Date: 23 Jan 1998 00:04:39 -0500
They do free it. They just wait for 10 hours to do so. It would be
unsafe to do it sooner.
This sounds like the right solution. (In fact it sounds like what
we're doing.)
Can you tell me which files are involved? I can find them eventually,
but this stuff is so convoluted it could take a while.
From: Tom Yu <tlyu@MIT.EDU>
To: "Charles Hedrick" <hedrick@geneva.rutgers.edu>
Cc: hedrick@nbcs.rutgers.edu, tlyu@MIT.EDU, krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/526: kadmind is leaking file descriptors
Date: Fri, 23 Jan 1998 00:11:20 -0500
Yeah. Anonymous ftp to athena-dist.mit.edu. Read the file
/pub/kerberos/README.KRB5-CURRENT. It will tell you the magic
filename you must use to get the current sources.
---Tom
From: "Charles Hedrick" <hedrick@geneva.rutgers.edu>
To: hedrick@geneva.rutgers.edu, tlyu@MIT.EDU
Cc: hedrick@nbcs.rutgers.edu, krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/526: kadmind is leaking file descriptors
Date: 23 Jan 1998 00:36:37 -0500
I meant which files in the source were changed in this particular
bug fix. I already know how to get krb5-current.
Thanks.
From: Tom Yu <tlyu@MIT.EDU>
To: "Charles Hedrick" <hedrick@geneva.rutgers.edu>
Cc: tlyu@MIT.EDU, hedrick@nbcs.rutgers.edu, krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/526: kadmind is leaking file descriptors
Date: Fri, 23 Jan 1998 15:17:44 -0500
Oh. Sorry. The files that were modified were in
src/lib/gssapi/krb5. The ChangeLog entries follow:
Wed Jan 21 19:14:09 1998 Tom Yu <tlyu@mit.edu>
* gssapiP_krb5.h: Add rcache member to the creds
structure. [krb5-libs/370]
* accept_sec_context.c (krb5_gss_accept_sec_context): Actually set
an rcache in auth context from the one saved in the creds
structure. [krb5-libs/370]
* acquire_cred.c (acquire_accept_cred): Set up an rcache for use
later. [krb5-libs/370]
* delete_sec_context.c (krb5_gss_delete_sec_context): Don't delete
the rcache when freeing the auth_context. [krb5-libs/370]
* rel_cred.c (krb5_gss_release_cred): Properly close the
rcache. [krb5-libs/370]
Anyway it's not a clean patch from 1.0.1, since there have been
changes on the mainline since then.
---Tom
State-Changed-From-To: feedback-closed
State-Changed-By: tlyu
State-Changed-When: Tue Sep 18 17:56:20 2001
State-Changed-Why:
Fixed long ago.
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id PAA06983 for <bugs@RT-11.MIT.EDU>; Tue, 13 Jan 1998 15:20:34 -0500
Received: from ns-dev.rutgers.edu by MIT.EDU with SMTP
id AA19324; Tue, 13 Jan 98 15:20:35 EST
Received: (from root@localhost)
by ns-dev.rutgers.edu (8.8.5/8.8.5) id PAA17673;
Tue, 13 Jan 1998 15:20:17 -0500 (EST)
Message-Id: <199801132020.PAA17673@ns-dev.rutgers.edu>
Date: Tue, 13 Jan 1998 15:20:17 -0500 (EST)
From: hedrick@nbcs.rutgers.edu
Reply-To: hedrick@nbcs.rutgers.edu
To: krb5-bugs@MIT.EDU
Subject: kadmind fast file descriptor leak
X-Send-Pr-Version: 3.99
Show quoted text
>Number: 526
>Category: krb5-admin
>Synopsis: kadmind is leaking file descriptors
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: tlyu
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Jan 13 15:21:00 EST 1998
>Last-Modified: Tue Sep 18 17:56:31 EDT 2001
>Originator: Charles Hedrick
>Organization:
Rutgers University>Category: krb5-admin
>Synopsis: kadmind is leaking file descriptors
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: tlyu
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Jan 13 15:21:00 EST 1998
>Last-Modified: Tue Sep 18 17:56:31 EDT 2001
>Originator: Charles Hedrick
>Organization:
Show quoted text
>Release: 1.0pl1
>Environment:
>Environment:
System: SunOS ns-dev.rutgers.edu 5.5.1 Generic sun4m sparc SUNW,SPARCstation-20
Architecture: sun4
Show quoted text
>Description:
Kadmind is leaking file descriptors. After a few hours, lsof shows
lots of fd's open on /usr/tmp/rc_kadmin_0.
I suspect that the replay cache is not working properly. The rcache
code doesn't seem to be designed to have multiple contexts working
with the same replay cache file name. In such a case I believe
invalid things will happen.
Show quoted text
>How-To-Repeat:
Change your password 64 times.
Show quoted text
>Fix:
The RPC mechanism is calling _svcauth_gssapi, krb5_gss_accept_sec_context,
krb5_rd_req, krb5_get_server_rcache. Krb5_gss_accept_sec_context
creates a new auth context. Since its rcache field is NULL,
krb5_rd_req calls krb5_get_server_rcache to create a new krb5_rcache.
The end result is a new rcache for each authenticator. This appears
to be invalid (though without real documentation for the library
calls, it's hard to be sure what is and isn't valid).
I propose to chance krb5_get_server_rcache to maintain a global
krb5_rcache. The first time it is called, the existing code
would be used to create one. All later times, the same
krb5_rcache would be returned.
Show quoted text
>Audit-Trail:
Responsible-Changed-From-To: bjaspan->tlyu
Responsible-Changed-By: tlyu
Responsible-Changed-When: Thu Jan 22 23:42:34 1998
Responsible-Changed-Why:
Mine!
State-Changed-From-To: open-feedback
State-Changed-By: tlyu
State-Changed-When: Thu Jan 22 23:42:48 1998
State-Changed-Why:
Should be fixed by patches to deal with [370]
From: Tom Yu <tlyu@MIT.EDU>
To: hedrick@nbcs.rutgers.edu
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/526: kadmind is leaking file descriptors
Date: Thu, 22 Jan 1998 23:48:59 -0500
The actual problem comes from the gssapi library calling krb5_rd_req
with an auth_context but without freeing the resultant rcache. If a
NULL auth_context were passed in, or if the rcache were then freed,
this wouldn't be a problem. Fortunately, another solution has been
provided by jik, who filed another bug report with fixes that would
allow the gssapi library to maintain a single rcache per server-side
gssapi credentials, resulting in a speedup as well as getting rid of
the problem with file descriptors leaking. I was able to connect
repeatedly to a kadmind in a tight loop without running out of file
descriptors. Please check a recent krb5-current snapshot (available
from athena-dist.mit.edu:/pub/kerberos) and tell me if the problem has
been fixed in our current sources.
---Tom
From: "Charles Hedrick" <hedrick@geneva.rutgers.edu>
To: hedrick@nbcs.rutgers.edu, tlyu@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/526: kadmind is leaking file descriptors
Date: 23 Jan 1998 00:04:39 -0500
Show quoted text
>The actual problem comes from the gssapi library calling krb5_rd_req
>with an auth_context but without freeing the resultant rcache. If a
>NULL auth_context were passed in, or if the rcache were then freed,
>this wouldn't be a problem. Fortunately, another solution has been
>with an auth_context but without freeing the resultant rcache. If a
>NULL auth_context were passed in, or if the rcache were then freed,
>this wouldn't be a problem. Fortunately, another solution has been
They do free it. They just wait for 10 hours to do so. It would be
unsafe to do it sooner.
Show quoted text
>provided by jik, who filed another bug report with fixes that would
>allow the gssapi library to maintain a single rcache per server-side
>gssapi credentials, resulting in a speedup as well as getting rid of
>the problem with file descriptors leaking. I was able to connect
>allow the gssapi library to maintain a single rcache per server-side
>gssapi credentials, resulting in a speedup as well as getting rid of
>the problem with file descriptors leaking. I was able to connect
This sounds like the right solution. (In fact it sounds like what
we're doing.)
Show quoted text
>repeatedly to a kadmind in a tight loop without running out of file
>descriptors. Please check a recent krb5-current snapshot (available
>from athena-dist.mit.edu:/pub/kerberos) and tell me if the problem has
>been fixed in our current sources.
>descriptors. Please check a recent krb5-current snapshot (available
>from athena-dist.mit.edu:/pub/kerberos) and tell me if the problem has
>been fixed in our current sources.
Can you tell me which files are involved? I can find them eventually,
but this stuff is so convoluted it could take a while.
From: Tom Yu <tlyu@MIT.EDU>
To: "Charles Hedrick" <hedrick@geneva.rutgers.edu>
Cc: hedrick@nbcs.rutgers.edu, tlyu@MIT.EDU, krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/526: kadmind is leaking file descriptors
Date: Fri, 23 Jan 1998 00:11:20 -0500
Show quoted text
>>>>> "CH" == Charles Hedrick <hedrick@geneva.rutgers.edu> writes:
Show quoted text
>> repeatedly to a kadmind in a tight loop without running out of file
>> descriptors. Please check a recent krb5-current snapshot (available
>> from athena-dist.mit.edu:/pub/kerberos) and tell me if the problem has
>> been fixed in our current sources.
>> descriptors. Please check a recent krb5-current snapshot (available
>> from athena-dist.mit.edu:/pub/kerberos) and tell me if the problem has
>> been fixed in our current sources.
Show quoted text
CH> Can you tell me which files are involved? I can find them eventually,
CH> but this stuff is so convoluted it could take a while.
CH> but this stuff is so convoluted it could take a while.
Yeah. Anonymous ftp to athena-dist.mit.edu. Read the file
/pub/kerberos/README.KRB5-CURRENT. It will tell you the magic
filename you must use to get the current sources.
---Tom
From: "Charles Hedrick" <hedrick@geneva.rutgers.edu>
To: hedrick@geneva.rutgers.edu, tlyu@MIT.EDU
Cc: hedrick@nbcs.rutgers.edu, krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/526: kadmind is leaking file descriptors
Date: 23 Jan 1998 00:36:37 -0500
Show quoted text
>CH> Can you tell me which files are involved? I can find them eventually,
>CH> but this stuff is so convoluted it could take a while.
>CH> but this stuff is so convoluted it could take a while.
Show quoted text
>Yeah. Anonymous ftp to athena-dist.mit.edu. Read the file
>/pub/kerberos/README.KRB5-CURRENT. It will tell you the magic
>filename you must use to get the current sources.
>/pub/kerberos/README.KRB5-CURRENT. It will tell you the magic
>filename you must use to get the current sources.
I meant which files in the source were changed in this particular
bug fix. I already know how to get krb5-current.
Thanks.
From: Tom Yu <tlyu@MIT.EDU>
To: "Charles Hedrick" <hedrick@geneva.rutgers.edu>
Cc: tlyu@MIT.EDU, hedrick@nbcs.rutgers.edu, krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/526: kadmind is leaking file descriptors
Date: Fri, 23 Jan 1998 15:17:44 -0500
Show quoted text
>>>>> "CH" == Charles Hedrick <hedrick@geneva.rutgers.edu> writes:
Show quoted text
CH> I meant which files in the source were changed in this particular
CH> bug fix. I already know how to get krb5-current.
CH> bug fix. I already know how to get krb5-current.
Oh. Sorry. The files that were modified were in
src/lib/gssapi/krb5. The ChangeLog entries follow:
Wed Jan 21 19:14:09 1998 Tom Yu <tlyu@mit.edu>
* gssapiP_krb5.h: Add rcache member to the creds
structure. [krb5-libs/370]
* accept_sec_context.c (krb5_gss_accept_sec_context): Actually set
an rcache in auth context from the one saved in the creds
structure. [krb5-libs/370]
* acquire_cred.c (acquire_accept_cred): Set up an rcache for use
later. [krb5-libs/370]
* delete_sec_context.c (krb5_gss_delete_sec_context): Don't delete
the rcache when freeing the auth_context. [krb5-libs/370]
* rel_cred.c (krb5_gss_release_cred): Properly close the
rcache. [krb5-libs/370]
Anyway it's not a clean patch from 1.0.1, since there have been
changes on the mainline since then.
---Tom
State-Changed-From-To: feedback-closed
State-Changed-By: tlyu
State-Changed-When: Tue Sep 18 17:56:20 2001
State-Changed-Why:
Fixed long ago.
Show quoted text
>Unformatted: