accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-4243) Kerberos thrift servers don't adhere to general.server.message.size.max
Date Thu, 26 May 2016 01:34:12 GMT


Josh Elser commented on ACCUMULO-4243:

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

Completely agree. I'm not even sure if it's something we can fix in Accumulo alone (might
require newer thrift) which would be terrifying as well. Either way, I haven't found/made
the time to actually dig into this yet; it doesn't need to block 1.7.2 IMO.

> Kerberos thrift servers don't adhere to general.server.message.size.max
> -----------------------------------------------------------------------
>                 Key: ACCUMULO-4243
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>          Components: rpc
>    Affects Versions: 1.7.0, 1.7.1
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Critical
>             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

View raw message