Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Fri, 22 Apr 2016 14:24:12 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12961655.1461334995000.8854.1461335052860@Atlassian.JIRA>
In-Reply-To: <JIRA.12961655.1461334995000@Atlassian.JIRA>
References: <JIRA.12961655.1461334995000@Atlassian.JIRA>
 <JIRA.12961655.1461334995560@arcas>
Subject: [jira] [Created] (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

Josh Elser created ACCUMULO-4243:
------------------------------------

             Summary: 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.1, 1.7.0
            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)