hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Phillips (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-5280) Allow YARN containers to run with Java Security Manager
Date Mon, 14 Nov 2016 13:46:58 GMT

    [ https://issues.apache.org/jira/browse/YARN-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15663962#comment-15663962

Greg Phillips commented on YARN-5280:

Thanks for reviewing the patch [~vvasudev].  
In effect this patch generates a temporary file (the java policy file) and modifies the container
command to use that file on a container by container basis.  To accomplish this using the
ContainerRuntime interface, the prepareContainer method seemed to be the best option considering
we want to modify the command before it is written to file.

1)  Currently the ContainerRuntime.prepareContainer doesn't appear to have any usages in the
standard execution of any containers.  LinuxContainerExecutor.writeLaunchEnv is passed all
of the information necessary to prepare the container runtime, and by overriding the method
any modifications made to the run command will be persisted to the launch file.  

2) For similar reasons to #1, the LinuxContainerExecutor seems to be the only class to use
the LinuxContainerRuntime interface.  The cleanup section of the ContainerExecutor.launchContainer
    } finally {
      try {
The postExecute() method appears to share a similar utility to the ContainerRuntime.reapContainer.

3) This patch proposes prepareContainer is executed in writeLaunchEnv.  WriteLaunchEnv is
not provided a context with the container which prevents us from using the ContainerRuntimeContext

To remedy these concerns we can do one of the following:
1. Find a different location for prepareContainer which executes prior to the execution environment
being written
2. Accept the modification to the prepareContainer interface since it is still in alpha/unstable
and is currently unused
3. Create an additional LinuxContainerExecutor which adds ~4 lines to the original (though
this doesn't resolve the issue of prepareContainer/reapContainer never being executed in 3.0.0-alpha1).

Thanks again for reviewing this patch.  I'm interested in your thoughts on the next steps
for this effort.  Additionally, I have another patch available which resolves the testing
errors in the previous jenkins run, and removes the use of YARN queues (i.e. no changes to
the MrAppMaster).

> Allow YARN containers to run with Java Security Manager
> -------------------------------------------------------
>                 Key: YARN-5280
>                 URL: https://issues.apache.org/jira/browse/YARN-5280
>             Project: Hadoop YARN
>          Issue Type: New Feature
>          Components: nodemanager, yarn
>    Affects Versions: 2.6.4
>            Reporter: Greg Phillips
>            Assignee: Greg Phillips
>            Priority: Minor
>              Labels: oct16-medium
>         Attachments: YARN-5280.001.patch, YARN-5280.002.patch, YARN-5280.003.patch, YARN-5280.004.patch,
YARN-5280.patch, YARNContainerSandbox.pdf
> YARN applications have the ability to perform privileged actions which have the potential
to add instability into the cluster. The Java Security Manager can be used to prevent users
from running privileged actions while still allowing their core data processing use cases.

> Introduce a YARN flag which will allow a Hadoop administrator to enable the Java Security
Manager for user code, while still providing complete permissions to core Hadoop libraries.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org

View raw message