----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/46228/#review155952 -----------------------------------------------------------
src/slave/slave.cpp (lines 2848 - 2850) <https://reviews.apache.org/r/46228/#comment226049> 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) <https://reviews.apache.org/r/46228/#comment226041> 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 > >
