You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@zookeeper.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2020/02/02 15:34:00 UTC

[jira] [Updated] (ZOOKEEPER-3711) Dispose SaslServer instances after use

     [ https://issues.apache.org/jira/browse/ZOOKEEPER-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ASF GitHub Bot updated ZOOKEEPER-3711:
--------------------------------------
    Labels: pull-request-available  (was: )

> Dispose SaslServer instances after use
> --------------------------------------
>
>                 Key: ZOOKEEPER-3711
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3711
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: server
>            Reporter: Damien Diederen
>            Assignee: Damien Diederen
>            Priority: Minor
>              Labels: pull-request-available
>
> The {{SaslServer}} instance held a {{ServerCnxn}} is not explicitly {{disposed()}} when the connection is closed.  This means that we are relying on the GC finalizer to release associated resources.
> While this does not seem to be problematic in practice, it would be better to explicitly {{dispose()}} the object at {{close()}} time.  This is unlikely to make a difference for managed providers, but {{-Dsun.security.jgss.native=true}} can potentially change the game.
> ----
> (For reference, in case somebody searches for this.)
> This came up while investigating a file descriptor leak related to the use of the native Sun provider.  The issue turned out *not* to be due to the missing dispose, but seems to be caused by a long-standing bug in the MIT Kerberos replay cache:
> https://github.com/xrootd/xrootd/issues/414
> {quote}
> Actually, this is a bug in the kerberos library as we really do close the cache but the descriptor may still leak. This is a known issue and has been fixed in various version of kerberos but apparently not in the version being used here. The only mitigation is to not export tickets (which is not necessary).
> {quote}
> The problem exists in MIT Kerberos 1.7.1, but will be fixed in 1.8—which replaces the problematic component by a new implementation:
> {noformat}
> commit e8a35f6962ce2d048616fb7457bff2d90398ca48
> Author: Greg Hudson <gh...@mit.edu>
> Date: Wed May 15 01:01:34 2019 -0400
>     Use file2 replay cache by default
>     
>     Remove the existing default replay cache implementation and replace it
>     with a wrapper around the file2 replay cache code. Change the
>     filename to krb5_EUID.rcache2, ignoring the residual (and therefore
>     the server principal name). On Windows, use the local appdata
>     directory if KRB5RCACHEDIR is not set in the environment.
>     
>     ticket: 8786
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)