I created https://issues.apache.org/jira/browse/MESOS-5680 to track.
Since this is no objection, we'll make sure the fix go into 1.0. - Jie On Tue, Jun 21, 2016 at 12:25 PM, Jie Yu <[email protected]> wrote: > James, sticky bit means that there will be no write sharing between two > users even if the underlying permission allows it. I'd prefer not having > this restriction:) > > I wonder whether ACLs are the right solution to volume ownership? >> Certainly I think inherited ACLs are a good solution for expressing a >> consistent access control policy over a hierarchy (at least in the >> Windows/Darwin/SMB/NFSv4/RichAcl ACL model). > > > Are you suggesting that we don't expose the underlying unix user directly > to frameworks. Instead, expressing permissions and ownerships using ACLs? > > - Jie > > On Tue, Jun 21, 2016 at 9:00 AM, James Peach <[email protected]> wrote: > >> Non-recursive chown is an improvement over recursive chown which seems >> fraught and should be avoided. For an interim fix, could you make the >> volume root world writeable with the sticky bit set? Then you wouldn't >> have to chown and volume users would still be able to create files. >> >> I wonder whether ACLs are the right solution to volume ownership? >> Certainly I think inherited ACLs are a good solution for expressing a >> consistent access control policy over a hierarchy (at least in the >> Windows/Darwin/SMB/NFSv4/RichAcl ACL model). >> >> On 20 June 2016 at 23:25, Jie Yu <[email protected]> wrote: >> > Hi folks, >> > >> > Currently, the ownership of the persistent volumes are set to be the >> same as >> > the sandbox. In the implementation, we call `chown -R` on the persistent >> > volume to match that of the sandbox each time before we mount it into >> the >> > container. >> > >> > Recently, we realized that this behavior is not ideal. Especially, if a >> task >> > created some files in the persistent volume, and the owner of those file >> > might be different than the task's user. For instance, a task is running >> > under root and it creates some database files under user 'database' and >> > launch the database process under user 'database'. When the database >> process >> > is restarted by the scheduler, the current behavior is that the we'll >> do a >> > 'chown -R root.root' on the persistent volume, causes database files to >> be >> > chown to 'root'. >> > >> > The true fix of this problem is to allow frameworks to explicit specify >> > owner of persistent volumes during creation. THis is captured in this >> > ticket: >> > https://issues.apache.org/jira/browse/MESOS-4893 >> > >> > In the short-term (for 1.0), I propose that, instead of doing a >> recursive >> > chown, we do a non-recursive chown. That'll allow the new task to at >> least >> > create new files under the persistent volume, but do not change >> ownership of >> > files created by previous tasks. It should be a very simple fix which >> we can >> > ship in 1.0. We'll ship MESOS-4893 after 1.0. What do you guys think? >> > >> > Thanks, >> > - Jie >> >> >> >> -- >> James Peach | [email protected] >> > >
