Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
0.26.0
-
Mesos 0.26.0, Apache Aurora 0.12
-
Mesosphere Sprint 60
-
3
Description
The filesystem/linux isolator is not a drop in replacement for the filesystem/shared isolator. This should be considered before the latter is deprecated.
We are currently using the filesystem/shared isolator together with the following slave option. This provides us with a private /tmp and /var/tmp folder for each task.
--default_container_info='{ "type": "MESOS", "volumes": [ {"host_path": "system/tmp", "container_path": "/tmp", "mode": "RW"}, {"host_path": "system/vartmp", "container_path": "/var/tmp", "mode": "RW"} ] }'
When browsing the Mesos sandbox, one can see the following permissions:
mode nlink uid gid size mtime drwxrwxrwx 3 root root 4 KB Apr 11 18:16 tmp drwxrwxrwx 2 root root 4 KB Apr 11 18:15 vartmp
However, when running with the new filesystem/linux isolator, the permissions are different:
mode nlink uid gid size mtime drwxr-xr-x 2 root root 4 KB Apr 12 10:34 tmp drwxr-xr-x 2 root root 4 KB Apr 12 10:34 vartmp
This prevents user code (running as a non-root user) from writing to those folders, i.e. every write attempt fails with permission denied.
Context:
- We are using Apache Aurora. Aurora is running its custom executor as root but then switches to a non-privileged user before running the actual user code.
- The follow code seems to have enabled our usecase in the existing filesystem/shared isolator: https://github.com/apache/mesos/blob/4d2b1b793e07a9c90b984ca330a3d7bc9e1404cc/src/slave/containerizer/mesos/isolators/filesystem/shared.cpp#L175-L198
Attachments
Issue Links
- is related to
-
MESOS-7830 Sandbox_path volume does not have ownership set correctly.
- Resolved