[
https://issues.apache.org/jira/browse/MESOS-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15380376#comment-15380376
]
Greg Mann edited comment on MESOS-5845 at 7/16/16 12:47 AM:
------------------------------------------------------------
While the fetcher does write to the cache, it looks like we segregate the cache
by user (see
[here|https://github.com/apache/mesos/blob/b1f71f1ba6c672982e84d4e607288537abed41c7/src/slave/containerizer/fetcher.cpp#L366-L370]).
Given that fact, it seems reasonable to run the fetcher as the task user - each
user's cache directory could be entirely owned by them. One complication is
that we currently create the user's cache directory in the fetcher binary; we
would probably need to change this to instead create the directory before we
spawn the fetcher subprocess, chown the directory to the task user, and then
run the fetcher as the task user.
One thought on the idea of having a special 'mesos' user: we definitely don't
want a non-root user to be able to grab root-protected files with the fetcher,
and it seems like a reasonable extension to say that we expect a given task
user to only be able to fetch files on the agent that the user has permission
to read. In that case, the appropriate thing is to enforce the task user's
permissions in the fetcher, either by checking permissions directly via
{{stat()}} or similar, or by running the fetcher binary as the task user.
What do you guys think? If we did run the whole fetcher as the task user, would
further patches for the decompression step be necessary, or might that resolve
MESOS-5218 as well?
was (Author: greggomann):
While the fetcher does write to the cache, it looks like we segregate the cache
by user:
https://github.com/apache/mesos/blob/b1f71f1ba6c672982e84d4e607288537abed41c7/src/slave/containerizer/fetcher.cpp#L366-L370
Given that fact, it seems reasonable to run the fetcher as the task user - each
user's cache directory could be entirely owned by them. One complication is
that we currently create the user's cache directory in the fetcher binary; we
would probably need to change this to instead create the directory before we
spawn the fetcher subprocess, chown the directory to the task user, and then
run the fetcher as the task user.
One thought on the idea of having a special 'mesos' user: we definitely don't
want a non-root user to be able to grab root-protected files with the fetcher,
and it seems like a reasonable extension to say that we expect a given task
user to only be able to fetch files on the agent that the user has permission
to read. In that case, the appropriate thing is to enforce the task user's
permissions in the fetcher, either by checking permissions directly via
{{stat()}} or similar, or by running the fetcher binary as the task user.
What do you guys think? If we did run the whole fetcher as the task user, would
further patches for the decompression step be necessary, or might that resolve
MESOS-5218 as well?
> The fetcher can access any local file as root
> ---------------------------------------------
>
> Key: MESOS-5845
> URL: https://issues.apache.org/jira/browse/MESOS-5845
> Project: Mesos
> Issue Type: Bug
> Reporter: Greg Mann
> Assignee: Greg Mann
> Labels: mesosphere
>
> The Mesos fetcher currently runs as root and does a blind cp+chown of any
> file:// URI into the task's sandbox, to be owned by the task user. Even if
> frameworks are restricted from running tasks as root, it seems they can still
> access root-protected files in this way. We should secure the fetcher so that
> it has the filesystem permissions of the user its associated task is being
> run as. One option would be to run the fetcher as the same user that the task
> will run as.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
