Skip Menu |
 

To: krb5-bugs@mit.edu
From: Gertjan Zwartjes <gertjan.zwartjes@me.com>
Subject: File descriptor leak?
Date: Wed, 20 Feb 2013 11:14:59 +0000 (GMT)
Download (untitled) / with headers
text/plain 1.6KiB
Hello,

I'm an Arch Linux user and I found the following issue with the latest Kerberos release (1.11).

With the latest krb5 bump from 1.10.x to 1.11, both Firefox and Chrome browsers break in combination with an HTTP proxy. For each browser proxy request a number (4?) of file descriptors are leaked. This will continue until the browser process has too many files open which will render both Firefox and Chrome unusable. They both stop loading internet pages. Firefox will also stop rendering fonts completely, even the user interface may degrade, where the tabs and menu's also don't show any fonts anymore.

I started noticing strange behavior with Firefox early this year. Both myself and a colleague have this issue on both i686 (my system) and x86_64 (colleague system). We've gone through great lengths figuring out what was going on, and ruled out anything else. Downgrading krb5 to 1.10.3 solves the issue.

It has something to do with the Kerberos credentials cache (the krb5cc_... file in /run/user). Another colleague using XFCE does not have this problem, because the credentials cache is not created at all for his system. The systems with the issue are running Gnome 3.

Another workaround is rm'ing the credentials cache directory before starting either Chrome or Firefox.

I have also reported this issue through the Arch Linux bug tracking system here: https://bugs.archlinux.org/task/33913. The request there is to discuss it with upstream development, that's why I am sending this email.

Please let me know if you need more information, or if there's anything I can help to debug the problem.

Thanks,

      Gertjan
Download (untitled) / with headers
text/plain 1.1KiB
This sounds important to fix, but after several hours of trying, I can't
reproduce an FD leak with GSSAPI authentication, either with various
forms of test programs or by running Firefox against 1.11 libraries.
Some notes for now:

* I'm assuming this HTTP proxy asks for negotiate auth. More details
about the proxy's HTTP responses might help narrow things down a bit.

* A leak of four FDs per connection sounds like a leak of a SPNEGO GSS
credential containing sub-credentials for the four Kerberos mech OID
variants, with a ccache handle per cred.

* If I'm reading the Firefox code properly, the invocation of GSSAPI for
negotiate auth is quite simple: a gss_import_name of a host-based name
for the target service, followed by a gss_import_sec_context with no
claimant cred, a mech of SPNEGO, and typically no req_flags (although
GSS_C_DELEG_FLAG can be specified if the service is matched by
network.negotiate-auth.delegation-uris).

* Looking at the krb5_gss_init_sec_context_ext code path for no claimant
handle, I don't see any paths where kg_get_defcred is called and the
resulting credential isn't released.
Subject: Re: [krbdev.mit.edu #7573] File descriptor leak?
From: Gertjan Zwartjes <gertjan.zwartjes@me.com>
Date: Thu, 21 Feb 2013 11:19:05 +0100
To: rt-comment@krbdev.mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.8KiB
It looks like it also has something to do with Gnome 3, which already triggers the creation of the credentials cache in /run/user/<userid>/krb5cc_...

Without that cache, for example using XFCE or by manually removing it, the problem does not surface.

If I look at the open file descriptors for Firefox, it's all fd's for the directory itself, while the directory remains empty during the browser run.

The proxy is a standard Windows environment company proxy, what tool could I use to find out more about the type of authentication?

Thanks for looking into this,

Gertjan

On Feb 20, 2013, at 8:19 PM, Greg Hudson via RT <rt-comment@krbdev.mit.edu> wrote:

Show quoted text
> This sounds important to fix, but after several hours of trying, I can't
> reproduce an FD leak with GSSAPI authentication, either with various
> forms of test programs or by running Firefox against 1.11 libraries.
> Some notes for now:
>
> * I'm assuming this HTTP proxy asks for negotiate auth. More details
> about the proxy's HTTP responses might help narrow things down a bit.
>
> * A leak of four FDs per connection sounds like a leak of a SPNEGO GSS
> credential containing sub-credentials for the four Kerberos mech OID
> variants, with a ccache handle per cred.
>
> * If I'm reading the Firefox code properly, the invocation of GSSAPI for
> negotiate auth is quite simple: a gss_import_name of a host-based name
> for the target service, followed by a gss_import_sec_context with no
> claimant cred, a mech of SPNEGO, and typically no req_flags (although
> GSS_C_DELEG_FLAG can be specified if the service is matched by
> network.negotiate-auth.delegation-uris).
>
> * Looking at the krb5_gss_init_sec_context_ext code path for no claimant
> handle, I don't see any paths where kg_get_defcred is called and the
> resulting credential isn't released.
I found the fd leak. From your original message I had assumed that with
GNOME 3 you actually had Kerberos credentials, but reading your second
message, it became clearer that you had an empty directory ccache.

I will check in the one-line fix imminently. You should get a message
soon with a link to the commit object on github. The Arch Linux
developers can either apply that fix manually, or wait for the 1.11.1
patch release, which should be out pretty soon.
From: ghudson@mit.edu
Subject: SVN Commit

Fix fd leak in DIR ccache cursor function

If dcc_ptcursor_next reached the end of a directory, it called free()
on the directory handle instead of closedir(), causing the directory
fd to be leaked. Call closedir() instead.

https://github.com/krb5/krb5/commit/c29d5f61af301aa8993b01ed0e3eb4f529d6862c
Author: Greg Hudson <ghudson@mit.edu>
Commit: c29d5f61af301aa8993b01ed0e3eb4f529d6862c
Branch: master
src/lib/krb5/ccache/cc_dir.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: tlyu@mit.edu
Subject: SVN Commit

Fix fd leak in DIR ccache cursor function

If dcc_ptcursor_next reached the end of a directory, it called free()
on the directory handle instead of closedir(), causing the directory
fd to be leaked. Call closedir() instead.

(cherry picked from commit c29d5f61af301aa8993b01ed0e3eb4f529d6862c)

https://github.com/krb5/krb5/commit/c47d02b2f191644eaf352b7e564d927fbd8b12d4
Author: Greg Hudson <ghudson@mit.edu>
Committer: Tom Yu <tlyu@mit.edu>
Commit: c47d02b2f191644eaf352b7e564d927fbd8b12d4
Branch: krb5-1.11
src/lib/krb5/ccache/cc_dir.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)