[
https://issues.apache.org/jira/browse/MAPREDUCE-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14623382#comment-14623382
]
Steve Loughran commented on MAPREDUCE-6429:
-------------------------------------------
Back in about 2008 I was running under a sandbox to stop things calling
System.exit(). The Hadoop security model itself was already incompatible with
that sandbox...with Kerberos and SPNEGO in there now, things will only have got
a lot, lot worse.
There's a more subtle issue, which is if you are allowing untrusted code within
a hadoop cluster, you need to worry about ddos-through scale actions which only
become visible under load. What if the tasks issued hundreds of nslookup calls
per second? Or created some directories in HDFS then executed lots of mv()
commands on them -per task. Or even just ran the CPUs at 100%, including FPU
and SSE/SSE2 units? Because all of those operations have already
unintentionally taken down datacentres.
I you are really trying to do some Hadoop-in-sandbox project, talk to some of
your colleagues about how to start an uber-JIRA where the core use cases of
sandboxing can be discussed, and whether it is viable to achieve such a goal
-and maintain it.
> running M/R tasks under a security policy
> -----------------------------------------
>
> Key: MAPREDUCE-6429
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6429
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: mrv2
> Affects Versions: 2.5.0
> Reporter: Purvesh Patel
> Priority: Minor
> Attachments: Patch.pdf
>
>
> When running M/R tasks under a security policy without the
> 'java.lang.reflect.ReflectPermission suppressAccessChecks' granted to the
> user code, we are unable to instantiate new keys for a WritableComparator.
> This patch wraps the WritableComparator#newKey in a doPrivileged block
> handling non-public key constructors. Please see attached file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
