Eric Badger commented on YARN-5534:

bq. For example(just made up), an admin may want to mount /data-volume into 
every container by some subset of users. container-executor.cfg should have a 
setting permitting the mounting of /data-volume but yarn-site.xml should have 
feature to mount it into every container for those users. Does that make sense?
I still don't see why the overall mounting setting would be in 
container-executor.cfg while the user-specific setting would be in 
yarn-site.xml. If we're looking at this from a security perspective, the volume 
mount is either a potential attack vector or not. If it's not, then we don't 
really care whether anyone can mount it and then I would say we should just put 
everything in yarn-site.xml. If we assume that it is a potential attack vector, 
then we very much care that only certain users can mount that volume. In that 
case, I don't see why we would put that whitelist of users in yarn-site.xml, if 
we're also assuming that yarn-site.xml is potentially untrusted (I assume the 
reason we're putting things into container-executor.cfg is because it is only 
root read/writable). 

So basically my main points are:
1. If yarn-site.xml is untrusted, then we can't put any configs with potential 
security-related consequences in there (e.g. which volumes are whitelisted)
2. If yarn-site.xml is trusted, then I don't know why we need to move any of 
the configs into container-executor.cfg

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

Reply via email to