Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 3 Aug 2017 01:42:01 +0000 (UTC)
From: "Vinod Kumar Vavilapalli (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12998105.1471500638000.80135.1501724521034@Atlassian.JIRA>
In-Reply-To: <JIRA.12998105.1471500638000@Atlassian.JIRA>
References: <JIRA.12998105.1471500638000@Atlassian.JIRA> <JIRA.12998105.1471500638705@jira-lw-us.apache.org>
Subject: [jira] [Commented] (YARN-5534) Allow whitelisted volume mounts
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 03 Aug 2017 01:42:07 -0000


    [ 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-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org