hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Yang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-7197) Add support for a volume blacklist for docker containers
Date Sat, 04 Nov 2017 00:01:06 GMT

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

Eric Yang commented on YARN-7197:

Hi [~jlowe], thank you for the review.  

I'm not sure I understand what you mean by "slip through" here.
One of the original blacklist examples you gave above showed /run/docker.socket in the blacklist,
and that's not a directory. That's going to prevent any mounting above that path because as
soon as it tries to mount a directory onto /run/docker.socket it's going to explode. Similarly
the unit test uses /etc/shadow as an example blacklist path. That prevents mounting /etc into
a container even if /etc is in the whitelist because the container will fail as soon as Docker
tries to mount a directory onto the /etc/shadow file. 

Explode might be exaggeration.  OS prevents the system call from succeeding, and Docker translate
the system exit code with a verbose message.  This does not cause any harm to OS.  "Slip through"
means mounting jailbreak directory to target path without OS denied the mount.  In the unit
test, {{test_docker_run_banned_mounts}} demonstrated that we can white list /etc, and black
list a child directory (result in mounting a empty directory) and any file type (they are
blocked by OS system call).  YARN will clean up container regardless successful creation or
not.  Therefore, additional code to check for something that OS also have check point seems

It is trivial to create these, they do not need to exist outside of the YARN installation.
The nodemanager could create a file in /tmp on startup, chmod it to a public file, and voila
– universal empty file that can be reused across containers. Or the container-executor could
create an empty file within the container's tmp under its working directory and mount that,
which makes it per-container and gets automatically cleaned up by YARN when the container
exits. Lots of ways to solve this problem.

File creation is easy, and it is easy to get it wrong too.  Someone on the host OS might add
additional files into files in /tmp or get erased by accident.  The default umask might not
be the same as OS default, therefore extra ownership system calls are required to secure the
newly created files.  Those operation can slow down the system.  Therefore, I decided to let
OS system call handle mismatch system call instead of adding more logic that might contain
even more holes.

 It doesn't look like we allocate nearly enough space for tmp_buffer_2 here since we're not
accounting for all of the hardcoded text or terminating NUL:

I think {{%s}} is extra characters counted toward required length for NULL.

> 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
>            Priority: Major
>         Attachments: YARN-7197.001.patch, YARN-7197.002.patch, YARN-7197.003.patch, YARN-7197.004.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

To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org

View raw message