[krbdev.mit.edu #7573] File descriptor leak?

[Gertjan Zwartjes via RT]

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 at krbdev.mit.edu> wrote:

> 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.