[
https://issues.apache.org/jira/browse/MESOS-9332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16690469#comment-16690469
]
Qian Zhang commented on MESOS-9332:
-----------------------------------
The above fix caused an issue that nested container may not have the permission
to write to its own sandbox. To reproduce it, just run `mesos-execute` with a
non-root user to launch the following task group:
{code:java}
{
"tasks":[
{
"name" : "test",
"task_id" : {"value" : "test"},
"agent_id": {"value" : ""},
"resources": [
{"name": "cpus", "type": "SCALAR", "scalar": {"value": 0.1}},
{"name": "mem", "type": "SCALAR", "scalar": {"value": 32}}
],
"command": {
"value": "pwd && touch file && sleep 1000"
}
}
]
}
{code}
And then we will see the task failed:
{code:java}
Received status update TASK_FAILED for task 'test'
message: 'Command exited with status 1'
source: SOURCE_EXECUTOR
{code}
The root cause of this issue is, the nested container was run as a non-root
user but its sandbox was created with root as owner.
{code:java}
I1117 01:13:49.864559 29988 containerizer.cpp:1246] Creating sandbox
'/home/qzhang/opt/mesos/slaves/3609f6a9-b6b3-4cf2-8d3c-4663af69784d-S0/frameworks/70104ebe-2066-4631-a318-a3c417e2d560-0000/executors/default-executor/runs/bd35f8af-25b6-49fe-8022-0efffd84e910/containers/9d84e3fe-4b0e-49df-a5a4-6d3f4bbd076a'
$ sudo ls -la
/home/qzhang/opt/mesos/slaves/3609f6a9-b6b3-4cf2-8d3c-4663af69784d-S0/frameworks/70104ebe-2066-4631-a318-a3c417e2d560-0000/executors/default-executor/runs/bd35f8af-25b6-49fe-8022-0efffd84e910/containers/9d84e3fe-4b0e-49df-a5a4-6d3f4bbd076a
total 8
drwxr-x---. 2 root root 34 Nov 17 01:13 .
drwxr-xr-x. 3 root root 50 Nov 17 01:13 ..
-rw-r--r--. 1 root root 67 Nov 17 01:13 stderr
-rw-r--r--. 1 root root 240 Nov 17 01:13 stdout
$ sudo cat
/home/qzhang/opt/mesos/slaves/3609f6a9-b6b3-4cf2-8d3c-4663af69784d-S0/frameworks/70104ebe-2066-4631-a318-a3c417e2d560-0000/executors/default-executor/runs/bd35f8af-25b6-49fe-8022-0efffd84e910/containers/9d84e3fe-4b0e-49df-a5a4-6d3f4bbd076a/stderr
Marked '/' as rslave
touch: cannot touch 'file': Permission denied
$ sudo cat
/home/qzhang/opt/mesos/slaves/3609f6a9-b6b3-4cf2-8d3c-4663af69784d-S0/frameworks/70104ebe-2066-4631-a318-a3c417e2d560-0000/executors/default-executor/runs/bd35f8af-25b6-49fe-8022-0efffd84e910/containers/9d84e3fe-4b0e-49df-a5a4-6d3f4bbd076a/stdout
/home/qzhang/opt/mesos/slaves/3609f6a9-b6b3-4cf2-8d3c-4663af69784d-S0/frameworks/70104ebe-2066-4631-a318-a3c417e2d560-0000/executors/default-executor/runs/bd35f8af-25b6-49fe-8022-0efffd84e910/containers/9d84e3fe-4b0e-49df-a5a4-6d3f4bbd076a
{code}
I will post a patch to fix this issue soon.
> Nested container should run as the same user of its parent container by
> default
> -------------------------------------------------------------------------------
>
> Key: MESOS-9332
> URL: https://issues.apache.org/jira/browse/MESOS-9332
> Project: Mesos
> Issue Type: Bug
> Components: containerization
> Reporter: Qian Zhang
> Assignee: Qian Zhang
> Priority: Major
> Labels: containerizer, mesosphere
> Fix For: 1.6.2, 1.7.1, 1.5.3
>
>
> Currently when launching a debug container, by default Mesos agent will use
> the executor's user as the debug container's user if the `user` field is not
> specified in the debug container's `commandInfo` (see [this
> code|https://github.com/apache/mesos/blob/1.7.0/src/slave/http.cpp#L2559] for
> details). This is OK for the command task since the command executor's user
> is same with command task's user (see [this
> code|https://github.com/apache/mesos/blob/1.7.0/src/slave/slave.cpp#L6068:L6070]
> for details), so the debug container will be launched as the same user of
> the task. But for the task in a task group, the default executor's user is
> same with the framework user (see [this
> code|https://github.com/apache/mesos/blob/1.7.0/src/slave/slave.cpp#L8959]
> for details), so in this case the debug container will be launched as the
> same user of the framework rather than the task. So in a scenario that
> framework user is a normal user but the task user is root, the debug
> container will be launched as the normal which is not desired, the
> expectation is the debug container should run as the same user of the
> container it debugs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
