accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Busbey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-4243) Kerberos thrift servers don't adhere to general.server.message.size.max
Date Wed, 25 May 2016 22:16:12 GMT

    [ 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)

Mime
View raw message