You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mesos.apache.org by qi...@apache.org on 2019/04/30 07:48:13 UTC
[mesos] branch 1.7.x updated (54719dd -> f0cbafd)
This is an automated email from the ASF dual-hosted git repository.
qianzhang pushed a change to branch 1.7.x
in repository https://gitbox.apache.org/repos/asf/mesos.git.
from 54719dd Added MESOS-9619 to the 1.7.3 CHANGELOG.
new beaae8d Made nested contaienr can access its sandbox via `MESOS_SANDBOX`.
new f0cbafd Added MESOS-9536 to the 1.7.3 CHANGELOG.
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
CHANGELOG | 1 +
src/slave/containerizer/mesos/containerizer.cpp | 24 +++++++++++++++------
.../mesos/isolators/filesystem/linux.cpp | 25 ++++++++++++++++++++++
3 files changed, 43 insertions(+), 7 deletions(-)
[mesos] 01/02: Made nested contaienr can access its sandbox via
`MESOS_SANDBOX`.
Posted by qi...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
qianzhang pushed a commit to branch 1.7.x
in repository https://gitbox.apache.org/repos/asf/mesos.git
commit beaae8df702e51102069b2b0502e924697ae36a2
Author: Qian Zhang <zh...@gmail.com>
AuthorDate: Fri Apr 19 17:22:45 2019 +0800
Made nested contaienr can access its sandbox via `MESOS_SANDBOX`.
Previously in MESOS-8332 we narrowed task sandbox permissions from 0755
to 0750 which will cause nested container may not has permission to
access its sandbox via the environment variable `MESOS_SANDBOX`. Now in
this patch, for nested container which does not have its own rootfs, we
bind mount its sandbox to the directory specified via the agent flag
`--sandbox_directory` and set `MESOS_SANDBOX` to `--sandbox_directory`
as well, in this way such nested container will have the permission
to access its sandbox via `MESOS_SANDBOX`.
Review: https://reviews.apache.org/r/70514
---
src/slave/containerizer/mesos/containerizer.cpp | 24 +++++++++++++++------
.../mesos/isolators/filesystem/linux.cpp | 25 ++++++++++++++++++++++
2 files changed, 42 insertions(+), 7 deletions(-)
diff --git a/src/slave/containerizer/mesos/containerizer.cpp b/src/slave/containerizer/mesos/containerizer.cpp
index e8a4ab3..1867f3b 100644
--- a/src/slave/containerizer/mesos/containerizer.cpp
+++ b/src/slave/containerizer/mesos/containerizer.cpp
@@ -1779,15 +1779,25 @@ Future<Containerizer::LaunchResult> MesosContainerizerProcess::_launch(
if (container->containerClass() == ContainerClass::DEFAULT) {
// TODO(jieyu): Consider moving this to filesystem isolator.
//
- // NOTE: For the command executor case, although it uses the host
- // filesystem for itself, we still set 'MESOS_SANDBOX' according to
- // the root filesystem of the task (if specified). Command executor
- // itself does not use this environment variable.
+ // NOTE: For the command executor case, although it uses the host filesystem
+ // for itself, we still set `MESOS_SANDBOX` according to the root filesystem
+ // of the task (if specified). Command executor itself does not use this
+ // environment variable. For nested container which does not have its own
+ // rootfs, if the `filesystem/linux` isolator is enabled, we will also set
+ // `MESOS_SANDBOX` to `flags.sandbox_directory` since in `prepare` method
+ // of the `filesystem/linux` isolator we bind mount such nested container's
+ // sandbox to `flags.sandbox_directory`. Since such bind mount is only done
+ // by the `filesystem/linux` isolator, if another filesystem isolator (e.g.,
+ // `filesystem/posix`) is enabled instead, nested container may still have
+ // no permission to access its sandbox via `MESOS_SANDBOX`.
Environment::Variable* variable = containerEnvironment.add_variables();
variable->set_name("MESOS_SANDBOX");
- variable->set_value(container->config->has_rootfs()
- ? flags.sandbox_directory
- : container->config->directory());
+ variable->set_value(
+ (container->config->has_rootfs() ||
+ (strings::contains(flags.isolation, "filesystem/linux") &&
+ containerId.has_parent()))
+ ? flags.sandbox_directory
+ : container->config->directory());
}
// `launchInfo.environment` contains the environment returned by
diff --git a/src/slave/containerizer/mesos/isolators/filesystem/linux.cpp b/src/slave/containerizer/mesos/isolators/filesystem/linux.cpp
index a47899c..93a88a0 100644
--- a/src/slave/containerizer/mesos/isolators/filesystem/linux.cpp
+++ b/src/slave/containerizer/mesos/isolators/filesystem/linux.cpp
@@ -202,6 +202,16 @@ Try<Isolator*> LinuxFilesystemIsolatorProcess::create(const Flags& flags)
}
}
+ // Create sandbox directory. We will bind mount the sandbox of nested
+ // container which does not have its own rootfs to this directory. See
+ // `prepare` for details.
+ Try<Nothing> mkdir = os::mkdir(flags.sandbox_directory);
+ if (mkdir.isError()) {
+ return Error(
+ "Failed to create sandbox directory at '" +
+ flags.sandbox_directory + "': " + mkdir.error());
+ }
+
Owned<MesosIsolatorProcess> process(
new LinuxFilesystemIsolatorProcess(flags));
@@ -395,6 +405,21 @@ Future<Option<ContainerLaunchInfo>> LinuxFilesystemIsolatorProcess::prepare(
mount->set_source(containerConfig.directory());
mount->set_target(sandbox);
mount->set_flags(MS_BIND | MS_REC);
+ } else if (containerId.has_parent()) {
+ // For nested container which does not have its own rootfs, bind mount its
+ // sandbox to the directory specified via `flags.sandbox_directory` (e.g.,
+ // `/mnt/mesos/sandbox`) in its own mount namespace and set the environment
+ // variable `MESOS_SANDBOX` to `flags.sandbox_directory` (see the `_launch`
+ // method of `MesosContainerizerProcess` for details). The reason that we do
+ // this is, in MESOS-8332 we narrowed task sandbox permissions from 0755 to
+ // 0750, since nested container's sandbox is subdirectory under its parent's
+ // sandbox, if we still set `MESOS_SANDBOX` to `containerConfig.directory()`
+ // for nested container, it will not have permission to access its sandbox
+ // via `MESOS_SANDBOX` if its user is different from its parent's user.
+ ContainerMountInfo* mount = launchInfo.add_mounts();
+ mount->set_source(containerConfig.directory());
+ mount->set_target(flags.sandbox_directory);
+ mount->set_flags(MS_BIND | MS_REC);
}
// Currently, we only need to update resources for top level containers.
[mesos] 02/02: Added MESOS-9536 to the 1.7.3 CHANGELOG.
Posted by qi...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
qianzhang pushed a commit to branch 1.7.x
in repository https://gitbox.apache.org/repos/asf/mesos.git
commit f0cbafdc82bfa9b93df01053c9b1bd5855dc0dba
Author: Qian Zhang <zh...@gmail.com>
AuthorDate: Tue Apr 30 09:47:24 2019 +0800
Added MESOS-9536 to the 1.7.3 CHANGELOG.
---
CHANGELOG | 1 +
1 file changed, 1 insertion(+)
diff --git a/CHANGELOG b/CHANGELOG
index 1fbeb1b..ae40637 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -6,6 +6,7 @@ Release Notes - Mesos - Version 1.7.3 (WIP)
* [MESOS-8467] - Destroyed executors might be used after `Slave::publishResource()`.
* [MESOS-9507] - Agent could not recover due to empty docker volume checkpointed files.
* [MESOS-9529] - `/proc` should be remounted even if a nested container set `share_pid_namespace` to true.
+ * [MESOS-9536] - Nested container launched with non-root user may not be able to write to its sandbox via the environment variable `MESOS_SANDBOX`.
* [MESOS-9549] - nvidia/cuda 10 does not work on GPU isolator.
* [MESOS-9564] - Logrotate container logger lets tasks execute arbitrary commands in the Mesos agent's namespace.
* [MESOS-9568] - SLRP does not clean up mount directories for destroyed MOUNT disks.