[
https://issues.apache.org/jira/browse/YARN-7197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217795#comment-16217795
]
Eric Badger edited comment on YARN-7197 at 10/24/17 10:12 PM:
--------------------------------------------------------------
Actually, thinking about this more, I'm wondering if this blacklist is going to
work at all in the way that has been proposed here. The aim, as I see it, is to
allow fairly permissive access at a high level and then cherry-pick things to
disallow access to beneath it. However, isn't this fundamentally broken since
we can just bind mount the higher level directory? Taking your example from
above
{quote}
For example, if a system admin would like to allow mounting of
/mnt/hdfs/user/$\{USER\} but not /mnt/hdfs/user/yarn using nfs gateway.
{quote}
If we allow /mnt/hdfs/user in the whitelist, then we can mount that directory
to get both /mnt/hdfs/user/$\{USER\} and /mnt/hdfs/user/yarn, which will be
underneath it. Adding /mnt/hdfs/user/yarn to the blacklist won't prevent us
from mounting /mnt/hdfs/user, which will then include /mnt/hdfs/user/yarn.
Unless there's a way to hide underlying files/directories in docker, I don't
see how this method can work. Please let me know if I'm mistaken and/or
misunderstanding something here.
was (Author: ebadger):
Actually, thinking about this more, I'm wondering if this blacklist is going to
work at all in the way that has been proposed here. The aim, as I see it, is to
allow fairly permissive access at a high level and then cherry-pick things to
disallow access to beneath it. However, isn't this fundamentally broken since
we can just bind mount the higher level directory? Taking your example from
above
bq. For example, if a system admin would like to allow mounting of
/mnt/hdfs/user/${USER} but not /mnt/hdfs/user/yarn using nfs gateway.
If we allow /mnt/hdfs/user in the whitelist, then we can mount that directory
to get both /mnt/hdfs/user/${USER} and /mnt/hdfs/user/yarn, which will be
underneath it. Adding /mnt/hdfs/user/yarn to the blacklist won't prevent us
from mounting /mnt/hdfs/user, which will then include /mnt/hdfs/user/yarn.
Unless there's a way to hide underlying files/directories in docker, I don't
see how this method can work. Please let me know if I'm mistaken and/or
misunderstanding something here.
> 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
