Re: Review Request 46228: Create persistent volume with a supplied user.

2017-03-01 Thread Joris Van Remoortere 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46228/#review167496
---



Closing this review due to inactivity. Please see our 
[guidelines](https://github.com/apache/mesos/blob/master/docs/reopening-reviews.md)
 for reopening reviews.

- Joris Van Remoortere


On Nov. 20, 2016, 4:50 p.m., Anindya Sinha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46228/
> ---
> 
> (Updated Nov. 20, 2016, 4:50 p.m.)
> 
> 
> Review request for mesos, Greg Mann and Jiang Yan Xu.
> 
> 
> Bugs: MESOS-4893
> https://issues.apache.org/jira/browse/MESOS-4893
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> If user is specified in Resource::DiskInfo::Persistence, set the
> ownership of the volume to that user. Tasks should have to comply to
> ownership of the volume before they can use the volume.
> If user is not specified in Resource::DiskInfo::Persistence, it is
> created with the user mesos-slave process runs as. When the first
> task is launched, it updates the ownership of the persistent volume
> with its user so as to be able to write into that volume.
> Note that tasks can fail to use the volume when they actually try
> to access the volume is that task's ownership is not compatible
> with that of the volume.
> 
> 
> Diffs
> -
> 
>   src/common/resources.cpp 4bb9beffcb3509f4226b4985e05eccec01412d0f 
>   src/slave/containerizer/docker.cpp c2ed5240aab9ea9d1a386c44c94e5ae7e98d313c 
>   src/slave/containerizer/mesos/isolators/filesystem/linux.cpp 
> 8f024d084189b59bb229c63d20108e7bfe42065f 
>   src/slave/containerizer/mesos/isolators/filesystem/posix.cpp 
> 270d2aa6e06f323bfb6eee3b703a24a600a55871 
>   src/slave/slave.cpp 521f08d59cd78f9089d58cd3294f0ee4a099cd7f 
>   src/v1/resources.cpp 46cc00f2f453f5eb4ddc4b0b9b89be2bd89f05d9 
> 
> 
> Diff: https://reviews.apache.org/r/46228/diff/3/
> 
> 
> Testing
> ---
> 
> All tests passed.
> 
> 
> Thanks,
> 
> Anindya Sinha
> 
>

Re: Review Request 46228: Create persistent volume with a supplied user.

2016-12-01 Thread Greg Mann 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46228/#review157686
---




src/slave/slave.cpp (lines 2923 - 2931)


Should we just add some validation code to the master that will prevent 
users from specifying the `user` field in `MOUNT` type disks, or is there a 
valid use case for such a volume resource?


- Greg Mann


On Nov. 20, 2016, 4:50 p.m., Anindya Sinha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46228/
> ---
> 
> (Updated Nov. 20, 2016, 4:50 p.m.)
> 
> 
> Review request for mesos, Greg Mann and Jiang Yan Xu.
> 
> 
> Bugs: MESOS-4893
> https://issues.apache.org/jira/browse/MESOS-4893
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> If user is specified in Resource::DiskInfo::Persistence, set the
> ownership of the volume to that user. Tasks should have to comply to
> ownership of the volume before they can use the volume.
> If user is not specified in Resource::DiskInfo::Persistence, it is
> created with the user mesos-slave process runs as. When the first
> task is launched, it updates the ownership of the persistent volume
> with its user so as to be able to write into that volume.
> Note that tasks can fail to use the volume when they actually try
> to access the volume is that task's ownership is not compatible
> with that of the volume.
> 
> 
> Diffs
> -
> 
>   src/common/resources.cpp 4bb9beffcb3509f4226b4985e05eccec01412d0f 
>   src/slave/containerizer/docker.cpp c2ed5240aab9ea9d1a386c44c94e5ae7e98d313c 
>   src/slave/containerizer/mesos/isolators/filesystem/linux.cpp 
> 8f024d084189b59bb229c63d20108e7bfe42065f 
>   src/slave/containerizer/mesos/isolators/filesystem/posix.cpp 
> 270d2aa6e06f323bfb6eee3b703a24a600a55871 
>   src/slave/slave.cpp 521f08d59cd78f9089d58cd3294f0ee4a099cd7f 
>   src/v1/resources.cpp 46cc00f2f453f5eb4ddc4b0b9b89be2bd89f05d9 
> 
> Diff: https://reviews.apache.org/r/46228/diff/
> 
> 
> Testing
> ---
> 
> All tests passed.
> 
> 
> Thanks,
> 
> Anindya Sinha
> 
>

Re: Review Request 46228: Create persistent volume with a supplied user.

2016-12-01 Thread Anindya Sinha 


> On Nov. 15, 2016, 8 p.m., Greg Mann wrote:
> > src/slave/slave.cpp, lines 2848-2850
> > 
> >
> > What's the rationale for including the sticky bit here? I wonder if the 
> > gain in security is worth the restriction?
> 
> Anindya Sinha wrote:
> The sticky bit ensures that the tasks only deletes files owned by it. 
> This is particularly true for shared volumes where multiple containers have 
> access to the same volume simultaneously and we would not like a running task 
> deleting content from the shared volume which is actually owned by another 
> running task at the same point of time.
> 
> Even for non-shared volumes, sticky bit can be enforced to disallow a 
> task deleting content from the volume which is owned by a preceding task. A 
> `DESTROY` of the volume is done using the user of mesos-slave process 
> (typically root) which should be able to `rmdir()` the directory to reclaim 
> the complete disk space.
> 
> Greg Mann wrote:
> OK sounds reasonable; I think this is something we should make explicit 
> in the documentation. Are there any docs changes in flight for this feature?

Yes, the last review in this chain, i.e. https://reviews.apache.org/r/46230


- Anindya


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46228/#review155952
---


On Nov. 20, 2016, 4:50 p.m., Anindya Sinha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46228/
> ---
> 
> (Updated Nov. 20, 2016, 4:50 p.m.)
> 
> 
> Review request for mesos, Greg Mann and Jiang Yan Xu.
> 
> 
> Bugs: MESOS-4893
> https://issues.apache.org/jira/browse/MESOS-4893
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> If user is specified in Resource::DiskInfo::Persistence, set the
> ownership of the volume to that user. Tasks should have to comply to
> ownership of the volume before they can use the volume.
> If user is not specified in Resource::DiskInfo::Persistence, it is
> created with the user mesos-slave process runs as. When the first
> task is launched, it updates the ownership of the persistent volume
> with its user so as to be able to write into that volume.
> Note that tasks can fail to use the volume when they actually try
> to access the volume is that task's ownership is not compatible
> with that of the volume.
> 
> 
> Diffs
> -
> 
>   src/common/resources.cpp 4bb9beffcb3509f4226b4985e05eccec01412d0f 
>   src/slave/containerizer/docker.cpp c2ed5240aab9ea9d1a386c44c94e5ae7e98d313c 
>   src/slave/containerizer/mesos/isolators/filesystem/linux.cpp 
> 8f024d084189b59bb229c63d20108e7bfe42065f 
>   src/slave/containerizer/mesos/isolators/filesystem/posix.cpp 
> 270d2aa6e06f323bfb6eee3b703a24a600a55871 
>   src/slave/slave.cpp 521f08d59cd78f9089d58cd3294f0ee4a099cd7f 
>   src/v1/resources.cpp 46cc00f2f453f5eb4ddc4b0b9b89be2bd89f05d9 
> 
> Diff: https://reviews.apache.org/r/46228/diff/
> 
> 
> Testing
> ---
> 
> All tests passed.
> 
> 
> Thanks,
> 
> Anindya Sinha
> 
>

Re: Review Request 46228: Create persistent volume with a supplied user.

2016-12-01 Thread Greg Mann 


> On Nov. 15, 2016, 8 p.m., Greg Mann wrote:
> > src/slave/slave.cpp, lines 2848-2850
> > 
> >
> > What's the rationale for including the sticky bit here? I wonder if the 
> > gain in security is worth the restriction?
> 
> Anindya Sinha wrote:
> The sticky bit ensures that the tasks only deletes files owned by it. 
> This is particularly true for shared volumes where multiple containers have 
> access to the same volume simultaneously and we would not like a running task 
> deleting content from the shared volume which is actually owned by another 
> running task at the same point of time.
> 
> Even for non-shared volumes, sticky bit can be enforced to disallow a 
> task deleting content from the volume which is owned by a preceding task. A 
> `DESTROY` of the volume is done using the user of mesos-slave process 
> (typically root) which should be able to `rmdir()` the directory to reclaim 
> the complete disk space.

OK sounds reasonable; I think this is something we should make explicit in the 
documentation. Are there any docs changes in flight for this feature?


- Greg


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46228/#review155952
---


On Nov. 20, 2016, 4:50 p.m., Anindya Sinha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46228/
> ---
> 
> (Updated Nov. 20, 2016, 4:50 p.m.)
> 
> 
> Review request for mesos, Greg Mann and Jiang Yan Xu.
> 
> 
> Bugs: MESOS-4893
> https://issues.apache.org/jira/browse/MESOS-4893
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> If user is specified in Resource::DiskInfo::Persistence, set the
> ownership of the volume to that user. Tasks should have to comply to
> ownership of the volume before they can use the volume.
> If user is not specified in Resource::DiskInfo::Persistence, it is
> created with the user mesos-slave process runs as. When the first
> task is launched, it updates the ownership of the persistent volume
> with its user so as to be able to write into that volume.
> Note that tasks can fail to use the volume when they actually try
> to access the volume is that task's ownership is not compatible
> with that of the volume.
> 
> 
> Diffs
> -
> 
>   src/common/resources.cpp 4bb9beffcb3509f4226b4985e05eccec01412d0f 
>   src/slave/containerizer/docker.cpp c2ed5240aab9ea9d1a386c44c94e5ae7e98d313c 
>   src/slave/containerizer/mesos/isolators/filesystem/linux.cpp 
> 8f024d084189b59bb229c63d20108e7bfe42065f 
>   src/slave/containerizer/mesos/isolators/filesystem/posix.cpp 
> 270d2aa6e06f323bfb6eee3b703a24a600a55871 
>   src/slave/slave.cpp 521f08d59cd78f9089d58cd3294f0ee4a099cd7f 
>   src/v1/resources.cpp 46cc00f2f453f5eb4ddc4b0b9b89be2bd89f05d9 
> 
> Diff: https://reviews.apache.org/r/46228/diff/
> 
> 
> Testing
> ---
> 
> All tests passed.
> 
> 
> Thanks,
> 
> Anindya Sinha
> 
>

Re: Review Request 46228: Create persistent volume with a supplied user.

2016-11-20 Thread Anindya Sinha 


> On Nov. 15, 2016, 8 p.m., Greg Mann wrote:
> > src/slave/slave.cpp, lines 2848-2850
> > 
> >
> > What's the rationale for including the sticky bit here? I wonder if the 
> > gain in security is worth the restriction?

The sticky bit ensures that the tasks only deletes files owned by it. This is 
particularly true for shared volumes where multiple containers have access to 
the same volume simultaneously and we would not like a running task deleting 
content from the shared volume which is actually owned by another running task 
at the same point of time.

Even for non-shared volumes, sticky bit can be enforced to disallow a task 
deleting content from the volume which is owned by a preceding task. A 
`DESTROY` of the volume is done using the user of mesos-slave process 
(typically root) which should be able to `rmdir()` the directory to reclaim the 
complete disk space.


> On Nov. 15, 2016, 8 p.m., Greg Mann wrote:
> > src/slave/slave.cpp, lines 2863-2872
> > 
> >
> > The `mkdir` is performed recursively; it looks like some parent 
> > directories may be left behind after this `rmdir` call?
> > 
> > It may be difficult to ensure that all directories are cleaned up 
> > without getting too entangled with the implementation of 
> > `getPersistentVolumePath`. Since `mkdir` can also leave directories behind 
> > if it fails in the middle of a recursive call, it's probably not a big deal 
> > if we leave something behind here as well, but perhaps you should include a 
> > comment indicating that this may happen?

Added a comment that we deem this transaction to succeed if we are able to 
successfully do a `mkdir()` followed by an optional `chown()` [if user is 
specified in the `CREATE` operation]. If any of these transactions fail, we do 
not allow the `CREATE` to succeed to ensure we do not leak persistent volumes.


- Anindya


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46228/#review155952
---


On Nov. 20, 2016, 4:50 p.m., Anindya Sinha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46228/
> ---
> 
> (Updated Nov. 20, 2016, 4:50 p.m.)
> 
> 
> Review request for mesos, Greg Mann and Jiang Yan Xu.
> 
> 
> Bugs: MESOS-4893
> https://issues.apache.org/jira/browse/MESOS-4893
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> If user is specified in Resource::DiskInfo::Persistence, set the
> ownership of the volume to that user. Tasks should have to comply to
> ownership of the volume before they can use the volume.
> If user is not specified in Resource::DiskInfo::Persistence, it is
> created with the user mesos-slave process runs as. When the first
> task is launched, it updates the ownership of the persistent volume
> with its user so as to be able to write into that volume.
> Note that tasks can fail to use the volume when they actually try
> to access the volume is that task's ownership is not compatible
> with that of the volume.
> 
> 
> Diffs
> -
> 
>   src/common/resources.cpp 4bb9beffcb3509f4226b4985e05eccec01412d0f 
>   src/slave/containerizer/docker.cpp c2ed5240aab9ea9d1a386c44c94e5ae7e98d313c 
>   src/slave/containerizer/mesos/isolators/filesystem/linux.cpp 
> 8f024d084189b59bb229c63d20108e7bfe42065f 
>   src/slave/containerizer/mesos/isolators/filesystem/posix.cpp 
> 270d2aa6e06f323bfb6eee3b703a24a600a55871 
>   src/slave/slave.cpp 521f08d59cd78f9089d58cd3294f0ee4a099cd7f 
>   src/v1/resources.cpp 46cc00f2f453f5eb4ddc4b0b9b89be2bd89f05d9 
> 
> Diff: https://reviews.apache.org/r/46228/diff/
> 
> 
> Testing
> ---
> 
> All tests passed.
> 
> 
> Thanks,
> 
> Anindya Sinha
> 
>

Re: Review Request 46228: Create persistent volume with a supplied user.

2016-11-20 Thread Anindya Sinha 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46228/
---

(Updated Nov. 20, 2016, 4:50 p.m.)


Review request for mesos, Greg Mann and Jiang Yan Xu.


Changes
---

addressed comments, and rebased.


Bugs: MESOS-4893
https://issues.apache.org/jira/browse/MESOS-4893


Repository: mesos


Description
---

If user is specified in Resource::DiskInfo::Persistence, set the
ownership of the volume to that user. Tasks should have to comply to
ownership of the volume before they can use the volume.
If user is not specified in Resource::DiskInfo::Persistence, it is
created with the user mesos-slave process runs as. When the first
task is launched, it updates the ownership of the persistent volume
with its user so as to be able to write into that volume.
Note that tasks can fail to use the volume when they actually try
to access the volume is that task's ownership is not compatible
with that of the volume.


Diffs (updated)
-

  src/common/resources.cpp 4bb9beffcb3509f4226b4985e05eccec01412d0f 
  src/slave/containerizer/docker.cpp c2ed5240aab9ea9d1a386c44c94e5ae7e98d313c 
  src/slave/containerizer/mesos/isolators/filesystem/linux.cpp 
8f024d084189b59bb229c63d20108e7bfe42065f 
  src/slave/containerizer/mesos/isolators/filesystem/posix.cpp 
270d2aa6e06f323bfb6eee3b703a24a600a55871 
  src/slave/slave.cpp 521f08d59cd78f9089d58cd3294f0ee4a099cd7f 
  src/v1/resources.cpp 46cc00f2f453f5eb4ddc4b0b9b89be2bd89f05d9 

Diff: https://reviews.apache.org/r/46228/diff/


Testing
---

All tests passed.


Thanks,

Anindya Sinha

Re: Review Request 46228: Create persistent volume with a supplied user.

2016-11-15 Thread Greg Mann 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46228/#review155952
---




src/slave/slave.cpp (lines 2848 - 2850)


What's the rationale for including the sticky bit here? I wonder if the 
gain in security is worth the restriction?



src/slave/slave.cpp (lines 2863 - 2872)


The `mkdir` is performed recursively; it looks like some parent directories 
may be left behind after this `rmdir` call?

It may be difficult to ensure that all directories are cleaned up without 
getting too entangled with the implementation of `getPersistentVolumePath`. 
Since `mkdir` can also leave directories behind if it fails in the middle of a 
recursive call, it's probably not a big deal if we leave something behind here 
as well, but perhaps you should include a comment indicating that this may 
happen?


- Greg Mann


On Oct. 18, 2016, 7:49 a.m., Anindya Sinha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46228/
> ---
> 
> (Updated Oct. 18, 2016, 7:49 a.m.)
> 
> 
> Review request for mesos, Greg Mann and Jiang Yan Xu.
> 
> 
> Bugs: MESOS-4893
> https://issues.apache.org/jira/browse/MESOS-4893
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> If user is specified in Resource::DiskInfo::Persistence, set the
> ownership of the volume to that user. Tasks should have to comply to
> ownership of the volume before they can use the volume.
> If user is not specified in Resource::DiskInfo::Persistence, it is
> created with the user mesos-slave process runs as. When the first
> task is launched, it updates the ownership of the persistent volume
> with its user so as to be able to write into that volume.
> Note that tasks can fail to use the volume when they actually try
> to access the volume is that task's ownership is not compatible
> with that of the volume.
> 
> 
> Diffs
> -
> 
>   src/common/resources.cpp 4bb9beffcb3509f4226b4985e05eccec01412d0f 
>   src/slave/containerizer/docker.cpp 8ec4c0a25335fb1b36cb2ab82577f6d3e2f7f008 
>   src/slave/containerizer/mesos/isolators/filesystem/linux.cpp 
> df16b8fee6799a69c7d96f33a5049bd9787c48f5 
>   src/slave/containerizer/mesos/isolators/filesystem/posix.cpp 
> 270d2aa6e06f323bfb6eee3b703a24a600a55871 
>   src/slave/slave.cpp 6bd9b49c3bbdb973a0d03552ae8fe55b33371083 
>   src/v1/resources.cpp 46cc00f2f453f5eb4ddc4b0b9b89be2bd89f05d9 
> 
> Diff: https://reviews.apache.org/r/46228/diff/
> 
> 
> Testing
> ---
> 
> All tests passed.
> 
> 
> Thanks,
> 
> Anindya Sinha
> 
>

Re: Review Request 46228: Create persistent volume with a supplied user.

2016-10-18 Thread Anindya Sinha 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46228/
---

(Updated Oct. 18, 2016, 7:45 a.m.)


Review request for mesos and Jiang Yan Xu.


Changes
---

Addressed review comments, and rebased.


Bugs: MESOS-4893
https://issues.apache.org/jira/browse/MESOS-4893


Repository: mesos


Description (updated)
---

If user is specified in Resource::DiskInfo::Persistence, set the
ownership of the volume to that user. Tasks should have to comply to
ownership of the volume before they can use the volume.
If user is not specified in Resource::DiskInfo::Persistence, it is
created with the user mesos-slave process runs as. When the first
task is launched, it updates the ownership of the persistent volume
with its user so as to be able to write into that volume.
Note that tasks can fail to use the volume when they actually try
to access the volume is that task's ownership is not compatible
with that of the volume.


Diffs (updated)
-

  src/common/resources.cpp 4bb9beffcb3509f4226b4985e05eccec01412d0f 
  src/slave/containerizer/docker.cpp 8ec4c0a25335fb1b36cb2ab82577f6d3e2f7f008 
  src/slave/containerizer/mesos/isolators/filesystem/linux.cpp 
df16b8fee6799a69c7d96f33a5049bd9787c48f5 
  src/slave/containerizer/mesos/isolators/filesystem/posix.cpp 
270d2aa6e06f323bfb6eee3b703a24a600a55871 
  src/slave/slave.cpp 6bd9b49c3bbdb973a0d03552ae8fe55b33371083 
  src/v1/resources.cpp 46cc00f2f453f5eb4ddc4b0b9b89be2bd89f05d9 

Diff: https://reviews.apache.org/r/46228/diff/


Testing
---

All tests passed.


Thanks,

Anindya Sinha

Re: Review Request 46228: Create persistent volume with a supplied user.

2016-10-04 Thread Greg Mann 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46228/#review149834
---




src/common/resources.cpp (line 146)


Is there a reason not to include the `principal` field in this equality 
operator?



src/slave/containerizer/mesos/isolators/filesystem/linux.cpp (line 675)


either:
s/user/the user/
or
s/user/`user`/



src/slave/slave.cpp (lines 2488 - 2502)


Looks like this bit will need some rebasing, since the volume creation code 
seems to have been factored out into a helper `syncCheckpointedResources`.



src/slave/slave.cpp (lines 2494 - 2495)


Could you enclose the code snippets in backticks? i.e.: `volume.has_disk() 
&& volume.disk().has_persistence()`


- Greg Mann


On April 14, 2016, 11:04 p.m., Anindya Sinha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46228/
> ---
> 
> (Updated April 14, 2016, 11:04 p.m.)
> 
> 
> Review request for mesos and Jiang Yan Xu.
> 
> 
> Bugs: MESOS-4893
> https://issues.apache.org/jira/browse/MESOS-4893
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> If user is specified in Resource::DiskInfo::Persistence, set the
> ownership of the volume to that user. Tasks should have to comply to
> ownership of the volume before they can use the volume.
> If user is not specified in Resource::DiskInfo::Persistence, it is
> created with the user mesos-slave process runs as. When a task is
> launched, it updates the ownership of the persistent volume with its
> user so as to be able to write into that persistent volume.
> 
> 
> Diffs
> -
> 
>   src/common/resources.cpp f6ff92b591c15bc8e93fd85e1896349c3a7bb968 
>   src/slave/containerizer/mesos/isolators/filesystem/linux.cpp 
> 9fc7c48f99155750fd3c18c7c102507e2726362b 
>   src/slave/containerizer/mesos/isolators/filesystem/posix.cpp 
> 01c0ad6dbb6d509e62e769365586b3d23dcb240d 
>   src/slave/slave.cpp de99e9eb5cc812b2e07deb749b98b4f4db363728 
>   src/v1/resources.cpp 8c3f2d1c1529915a59d47fe37bb3fc7a3267079a 
> 
> Diff: https://reviews.apache.org/r/46228/diff/
> 
> 
> Testing
> ---
> 
> All tests passed.
> 
> 
> Thanks,
> 
> Anindya Sinha
> 
>

Review Request 46228: Create persistent volume with a supplied user.

2016-04-14 Thread Anindya Sinha 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46228/
---

Review request for mesos and Jiang Yan Xu.


Bugs: MESOS-4893
https://issues.apache.org/jira/browse/MESOS-4893


Repository: mesos


Description
---

If user is specified in Resource::DiskInfo::Persistence, set the
ownership of the volume to that user. Tasks should have to comply to
ownership of the volume before they can use the volume.
If user is not specified in Resource::DiskInfo::Persistence, it is
created with the user mesos-slave process runs as. When a task is
launched, it updates the ownership of the persistent volume with its
user so as to be able to write into that persistent volume.


Diffs
-

  src/common/resources.cpp f6ff92b591c15bc8e93fd85e1896349c3a7bb968 
  src/slave/containerizer/mesos/isolators/filesystem/linux.cpp 
9fc7c48f99155750fd3c18c7c102507e2726362b 
  src/slave/containerizer/mesos/isolators/filesystem/posix.cpp 
01c0ad6dbb6d509e62e769365586b3d23dcb240d 
  src/slave/slave.cpp de99e9eb5cc812b2e07deb749b98b4f4db363728 
  src/v1/resources.cpp 8c3f2d1c1529915a59d47fe37bb3fc7a3267079a 

Diff: https://reviews.apache.org/r/46228/diff/


Testing
---

All tests passed.


Thanks,

Anindya Sinha