[
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 includes:
{code:java}
} finally {
resourcesHandler.postExecute(containerId);
try {
linuxContainerRuntime.reapContainer(runtimeContext);
{code}
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 builder.
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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
