hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vinod Kumar Vavilapalli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-5534) Allow whitelisted volume mounts
Date Thu, 03 Aug 2017 01:42:01 GMT

    [ 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

> 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

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

View raw message