[
https://issues.apache.org/jira/browse/MESOS-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14955179#comment-14955179
]
Vasilis Vasaitis commented on MESOS-3711:
-----------------------------------------
Yes, the Mesos agent itself in our setup is typically run as root. And also
yes, our agent hosts don't really have any user information (they don't
synchronize with LDAP or anything like that) so there is no expectation that
the specified user will exist on the host side of the agent. And even if they
did, the idea here is to shield the creator of the Docker image from the
configuration of the host side of the agent: the image is created with some
user inside its own {{/etc/passwd}}, and with various files owned by that user;
if that username is then baked into the image, and the execution environment
supports that, then the container can run blissfully unaware of the user setup
on the host side of the agent. And I'm under the impression that the only
obstacle that is right now preventing such a setup from working is the
ownership/permissions of the top-level sandbox, as described above.
Also, I'm not sure if Aurora specifies a user anyway the proper Mesos way, or
if passes that information out-of-band to the Thermos executor via their own
structures. But in any case having that user information propagated properly is
kinda orthogonal to the use case I'm describing, because the whole point is to
make the Docker image self-contained and _independent_ of the user who will be
running the task, so that the running container will exhibit the same behaviour
regardless of which user is launching it.
Am I making much sense? Do you think that's a reasonable use case worth
enabling?
> 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)
