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

Vinod Kumar Vavilapalli commented on YARN-5534:
-----------------------------------------------

bq. In general I think this is redundant. Each feature should have only one 
config location otherwise it affect usability (for the admins).
The reason why we need it both areas is because (a) the java land only reads 
yarn-site.xml and the C land only reads container-executor.cfg and both need to 
know if a feature is enabled or not (b) the files have different ownerships - 
yarn user vs root.

This is an existing pattern given the NM -> Container-Executor separation. 
Unrolling it would mostly mean forcing the java land also read 
container-executor.cfg. The opposite will likely not happen - C land reading 
multiple config files will increase the surface area.

bq. getCGroupsCpuResourceHandler(), where any of the config settings implied 
that the user needs a resource handler without any other config knob.
getCGroupsCpuResourceHandler() works because all the cgroups heavy-lifting is 
done in the java land and so this split code problem doesn't exist there. There 
is only one privileged operation in the c land - setup of cgroups, which one 
can argue shouldn't be enabled by default either.


> Allow whitelisted volume mounts 
> --------------------------------
>
>                 Key: YARN-5534
>                 URL: https://issues.apache.org/jira/browse/YARN-5534
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: yarn
>            Reporter: luhuichun
>            Assignee: Shane Kumpf
>         Attachments: YARN-5534.001.patch, YARN-5534.002.patch, 
> YARN-5534.003.patch
>
>
> Introduction 
> Mounting files or directories from the host is one way of passing 
> configuration and other information into a docker container. 
> We could allow the user to set a list of mounts in the environment of 
> ContainerLaunchContext (e.g. /dir1:/targetdir1,/dir2:/targetdir2). 
> These would be mounted read-only to the specified target locations. This has 
> been resolved in YARN-4595
> 2.Problem Definition
> Bug mounting arbitrary volumes into a Docker container can be a security risk.
> 3.Possible solutions
> one approach to provide safe mounts is to allow the cluster administrator to 
> configure a set of parent directories as white list mounting directories.
>  Add a property named yarn.nodemanager.volume-mounts.white-list, when 
> container executor do mount checking, only the allowed directories or 
> sub-directories can be mounted. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Reply via email to