[
https://issues.apache.org/jira/browse/ACCUMULO-4243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated ACCUMULO-4243:
--------------------------------
Fix Version/s: (was: 1.7.2)
1.7.3
> 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: Critical
> Fix For: 1.7.3, 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)
