mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Downes (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MESOS-3711) Docker containers running as other than root can't access sandbox
Date Tue, 13 Oct 2015 00:19:05 GMT

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

Ian Downes commented on MESOS-3711:
-----------------------------------

The task work directory (the top-level sandbox) is created and chown'ed to the user specified
by the task, assuming one is specified and {{--switch_user is true}} (default), otherwise
it's created and chown'ed to the user running the slave. See {{paths::createExecutorDirectory()}}
as used during {{launchExecutor()}} in {{slave/slave.cpp}}.

This doesn't seem to match your stated behavior: if the task does specify the user then the
top-level sandbox will be chown'ed to that user and Thermos, running as that user, should
be okay to create the sandbox subdirectory.

*BUT*, note the TODO comment from [~nnielsen] (nnielsen) in the implementation of {{createExecutorDirectory()}}
and the implications: the user *name* is used for the chown so the chown call will fail if
the name doesn't resolve to a UID on the host (i.e., is present in {{/etc/passwd}}). Furthermore,
*it's only logged with a warning and the slave will continue with the executor work directory
owned by the user running the slave*, I assume this is root? So, what I think is happening
is you are specifying a user name that (at some point) was valid inside the container filesystem
(mapped to a UID) but is not valid on the host when launching the container (not present in
the host's {{/etc/passwd}}). Does that make sense?

> Docker containers running as other than root can't access sandbox
> -----------------------------------------------------------------
>
>                 Key: MESOS-3711
>                 URL: https://issues.apache.org/jira/browse/MESOS-3711
>             Project: Mesos
>          Issue Type: Bug
>          Components: containerization, docker
>            Reporter: Vasilis Vasaitis
>
> (Disclaimer: I'm not the one running the Mesos infrastructure in my org, and I don't
necessarily fully understand how all the moving parts fit together, so please bear with me
if there any gaps in my understanding of the issues at hand.)
> We have a setup here where we deploy Docker-based tasks on Mesos, using Aurora (and thus
the Thermos executor, on the agent side). As part of the process of launching a task, it looks
like the Mesos agent creates / volume-mounts an {{/mnt/mesos/sandbox}} directory, which is
what's used as the task's sandbox. Thermos then creates a {{sandbox}} subdirectory _inside_
that, and the aggregate {{/mnt/mesos/sandbox/sandbox}} is in fact the directory that the user
application is given. So far so good.
> Now, Docker has the option, during the creation of a Docker image, to specify the _user_
that any container launched using this image will be run as. This is a useful feature, because
often the image is built so that only one particular user has ownership of important files
etc. One could of course sidestep this issue by always launching the container as root, but
that can be unsavoury for its own reasons.
> However, with the setup I described above, specifying a user for the Docker container
quickly goes south: the Thermos executor itself is launched as that user, tries to create
that extra {{sandbox}} directory, and fails, because the parent directory is owned by root.
> I won't claim to know whether this is the _best_ approach, but one possible solution
to this problem is to chmod 1777 the parent sandbox directory (i.e., set the sticky bit, like
{{/tmp}}) after creating it; this way any user can create files/directories under it, without
compromising the isolation between users.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message