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

Eric Badger commented on YARN-7197:
-----------------------------------

[~eyang]

bq. Symlink are banned to prevent mistakes. I can lift the symlink check and 
trust that system admin will always express physical path correctly instead of 
symlink paths in black list
I think that if we're going to allow symlinks in the whitelist case then we 
should allow them here as well. Also, allowing symlinks in the white/black 
lists can be useful. For example, if you have /hadoop symlinked to the most 
recent hadoop version, maybe you want to add that to the whitelist, but you 
don't want to change the whitelist everytime you update your hadoop version. 

{quote}
I did not separate black list for read-only and read-write to reduce wordy 
configurations that could generate security holes. For example, if someone 
would like to mount /run as read only, and allow docket.socket to be used 
inside container.
Should they specify?
white-listed-read-only: /run
white-listed-read-write: /run/docker.socket
black-listed-read-only:/run/docker.socket
black-listed-read-write: /run
Or?
white-listed-read-only: /run
white-listed-read-write: /run/docker.socket
black-listed-read-only: /run/docker.socket
Ideally, user should be able to specify the minimum to get the system to work:
white-listed-read-only: /run
white-listed-read-write: /run/docker.socket
or
white-listed-read-only: /run
white-listed-read-write: /run/docker.socket
black-listed: /var/run
{quote}
Even with the blacklist split up into ro and rw, why wouldn't they be able to 
simply add what they want to the whitelist and not bother with the blacklist? 
Splitting the blacklist gives you more fine-grained control over exactly what 
you want to disallow. For example, if you had a directory where you wanted to 
be able to mount almost everything as rw, except for a few things. Then you'd 
whitelist the whole directory as rw and use the blacklist to disallow the 
specific directories as ro/rw. Maybe you have a keytab under one of those 
directories that you need to disallow rw access and you have a conf directory 
that you only want to be read, not written. If you don't split up the blacklist 
then you would lose the ro/rw control on those files and they would have to be 
either all or nothing.

> Add support for a volume blacklist for docker containers
> --------------------------------------------------------
>
>                 Key: YARN-7197
>                 URL: https://issues.apache.org/jira/browse/YARN-7197
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: yarn
>            Reporter: Shane Kumpf
>            Assignee: Eric Yang
>         Attachments: YARN-7197.001.patch, YARN-7197.002.patch
>
>
> Docker supports bind mounting host directories into containers. Work is 
> underway to allow admins to configure a whilelist of volume mounts. While 
> this is a much needed and useful feature, it opens the door for 
> misconfiguration that may lead to users being able to compromise or crash the 
> system. 
> One example would be allowing users to mount /run from a host running 
> systemd, and then running systemd in that container, rendering the host 
> mostly unusable.
> This issue is to add support for a default blacklist. The default blacklist 
> would be where we put files and directories that if mounted into a container, 
> are likely to have negative consequences. Users are encouraged not to remove 
> items from the default blacklist, but may do so if necessary.



--
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