Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Wed, 25 May 2016 22:16:12 +0000 (UTC)
From: "Sean Busbey (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12961655.1461334995000.295464.1464214572987@Atlassian.JIRA>
In-Reply-To: <JIRA.12961655.1461334995000@Atlassian.JIRA>
References: <JIRA.12961655.1461334995000@Atlassian.JIRA> <JIRA.12961655.1461334995560@arcas>
Subject: [jira] [Commented] (ACCUMULO-4243) Kerberos thrift servers don't
 adhere to general.server.message.size.max
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 25 May 2016 23:09:26 -0000


    [ https://issues.apache.org/jira/browse/ACCUMULO-4243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300972#comment-15300972 ] 

Sean Busbey commented on ACCUMULO-4243:
---------------------------------------

Any progress here? Since this has already been in two 1.7.z releases and is only present with an optional feature enabled, could we consider lowering to Critical priority?

> Kerberos thrift servers don't adhere to general.server.message.size.max
> -----------------------------------------------------------------------
>
>                 Key: ACCUMULO-4243
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4243
>             Project: Accumulo
>          Issue Type: Bug
>          Components: rpc
>    Affects Versions: 1.7.0, 1.7.1
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Blocker
>             Fix For: 1.7.2, 1.8.0
>
>
> It looks like when I implemented Kerberos client authentication in ACCUMULO-2815, I botched the use of general.server.message.size.max.
> This property is meant to guard us against trying to allocate a very large buffer from an RPC call. Typically, the first four bytes of data sent to one of our thrift servers (tserver, master, proxy) is treated as the number of bytes to read for some RPC. The problem is that if some garbage data (often, a security scan by some admins) may inadvertently cause the server to try to allocate a very large buffer (GBs in size) which will cause the process to ultimately crash while instantiating the buffer.
> It seems like something might be handled differently in the TSaslServer in Thrift. I'll have to dig more into whether it's an Accumulo or Thrift bug.
> To reproduce this, I was able to use telnet:
> {noformat}
> $ telnet `hostname -f` 9997
> <...waiting to get connected...>
> ~~~~000000000000000000
> ..
> {noformat}
> This will try to create a very large buffer (~2.1GB). I observed this by hooking up jvisualvm to the tabletserver.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)