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

Eric Badger commented on YARN-5534:
-----------------------------------

I emailed [~miklos.szeg...@cloudera.com] about this offline, but I'd like to 
get some additional perspectives here possibly from [~vvasudev], 
[~shaneku...@gmail.com], [~vinodkv], [~dan...@cloudera.com], [~jlowe]. My 
thoughts on the matter are in the email I sent to 
[~miklos.szeg...@cloudera.com] below. The overall question is whether we should 
be putting the docker configs in yarn-site.xml, container-executor.cfg, some in 
each, or some/all in both. I would like to come to a consensus so that we can 
move forward on this JIRA and others. 

{quote}
I'm a little confused about a few things here. First, putting docker properties 
in multiple places seems like a bad idea for the less than expert admin. They 
will see some configs in one place (yarn-site.xml or container-executor.cfg) 
and assume that those are all of the configs when really there's others in a 
different place. Maybe this is more of an inconvenience, but it doesn't make 
sense to me to have them in 2 different places. 

Second, I don't see why some properties should be protected under the veil of 
root via the container-executor.cfg but not others. In the current docker 
implementation, you get to specify the image that you want to use. I could 
easily put a setuid binary in there and get root in the container. There are 
constantly new exploits on how to get out of the container if you get root 
(assuming you're not using user namespace remapping, which we aren't). This 
could possibly be mitigated by dropping the SETUID capability for the 
container, but that's also a property in yarn-site.xml and not 
container-executor.cfg. So I don't see why the volume whitelist belongs in 
container-executor.cfg, but these other properties belong in yarn-site.xml. 
Seems like they should all belong in container-executor.cfg or none of them 
should. 
{quote}

I'm not sure if this is the best place for discussion to occur since this topic 
is bigger than simply whitelisting volume mounts. If there's a better place, 
then we can move the discussion there. 

> 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