Re: Volume ownership and permission
> >>>> On Apr 26, 2018, at 7:25 PM, Qian Zhang wrote: > >>>> > >>>> Hi James, > >>>> > >>>> Thanks for your comment! > >>>> > >>>> I think you are talking about the SANDBOX_PATH volume ownership issue > >>>> mentioned in the design doc > >>>> <https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE > >>> -v4KWwjmnCR0l8V4Tq2U/edit#heading=h.s6f8rmu65g2p>, > >>>> IIUC, you prefer to leaving it to framework, i.e., framework itself > >>> ought > >>>> to be able to handle such issue. But I am curious how framework can > >>> handle > >>>> it in such situation. If the framework launches a task group with > >>> different > >>>> users and with a SANDBOX_PATH volume of PARENT type, the tasks in the > >>> group > >>>> will definitely fail to write to the volume due to the ownership issue > >>>> though the volume's mode is set to "rw". So in this case, how should > >>>> framework handle it? > >>> > >>> The framework launched tasks in a group with different users? Sounds > like > >>> they dug their own hole :) > >>> > >>> I'd argue that the "rw" on the sandbox path is analogous to the "rw" > >>> mount option. That is, it is mounted writeable, but says nothing about > >>> which credentials can write to it. > >>> > >>>> And if we want to document it, what is our recommended > >>>> solution in the doc? > >>>> > >>>> > >>>> > >>>> Regards, > >>>> Qian Zhang > >>>> > >>>> On Fri, Apr 27, 2018 at 1:16 AM, James Peach > wrote: > >>>> > >>>>> I commented on the doc, but at least some of the issues raised there > I > >>>>> would not regard as issues. Rather, they are about setting > expectations > >>>>> correctly and ensuring that we are documenting (and maybe enforcing) > >>>>> sensible behavior. > >>>>> > >>>>> I'm not that keen on Mesos automatically "fixing" filesystem > >>> permissions > >>>>> and we should proceed down that path with caution, especially in the > >>> ACLs > >>>>> case. > >>>>> > >>>>>> On Apr 10, 2018, at 3:15 AM, Qian Zhang > wrote: > >>>>>> > >>>>>> Hi Folks, > >>>>>> > >>>>>> I am working on MESOS-8767 to improve Mesos volume support regarding > >>>>> volume ownership and permission, here is the design doc. Please feel > >>> free > >>>>> to let me know if you have any comments/feedbacks, you can reply this > >>> mail > >>>>> or comment on the design doc directly. Thanks! > >>>>>> > >>>>>> > >>>>>> Regards, > >>>>>> Qian Zhang > >>>>> > >>>>> > >>> > >>> > >> > >
Re: Volume ownership and permission
> On Aug 15, 2018, at 6:22 PM, Qian Zhang wrote: > > Hi Folks, > > We found some issues for the solutions of this project and propose a better > one, see here > <https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE-v4KWwjmnCR0l8V4Tq2U/edit#heading=h.tjuy5xk67tuu> > for details. Please let me know if you have any comments, thanks! Some general comments. I assume that this scheme will only be supported on Linux, due to the dependencies on the Linux ACLs and supplementary group behaviour? Rewriting ACLs on volumes at each container launch sounds hugely expensive. It's IOP-bound process and there are an effectively unbounded number of files in the volume. Would this serialize container cleanup? It seems like ACL evaluation will mean that this scheme will only mostly work. For example, if the container process UID matches a user ACE, then access could be denied independently of the volume policy. Will the VolumeAclManager apply a default ACL on the root of the volume? Does this imply that when it updates the ACEs for the container GID, it also needs to update the default ACLs on all directories? > > > Regards, > Qian Zhang > > On Sat, Apr 28, 2018 at 7:57 AM, Qian Zhang wrote: > >>> The framework launched tasks in a group with different users? Sounds >> like they dug their own hole :) >> >> So you mean we should actually put a best practice or limitation in doc: >> when launching a task group with multiple tasks to share a SANDBOX volume >> of PARENT type, all the tasks should be run with the same user, and that >> user must be same with the user to launch the executor? Otherwise the task >> will not be able to write to the volume. >> >>> I'd argue that the "rw" on the sandbox path is analogous to the "rw" >> mount option. That is, it is mounted writeable, but says nothing about >> which credentials can write to it. >> >> Can you please elaborate a bit on this? What would you suggest for the >> "rw` volume mode? >> >> >> Regards, >> Qian Zhang >> >> On Fri, Apr 27, 2018 at 12:07 PM, James Peach wrote: >> >>> >>> >>>> On Apr 26, 2018, at 7:25 PM, Qian Zhang wrote: >>>> >>>> Hi James, >>>> >>>> Thanks for your comment! >>>> >>>> I think you are talking about the SANDBOX_PATH volume ownership issue >>>> mentioned in the design doc >>>> <https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE >>> -v4KWwjmnCR0l8V4Tq2U/edit#heading=h.s6f8rmu65g2p>, >>>> IIUC, you prefer to leaving it to framework, i.e., framework itself >>> ought >>>> to be able to handle such issue. But I am curious how framework can >>> handle >>>> it in such situation. If the framework launches a task group with >>> different >>>> users and with a SANDBOX_PATH volume of PARENT type, the tasks in the >>> group >>>> will definitely fail to write to the volume due to the ownership issue >>>> though the volume's mode is set to "rw". So in this case, how should >>>> framework handle it? >>> >>> The framework launched tasks in a group with different users? Sounds like >>> they dug their own hole :) >>> >>> I'd argue that the "rw" on the sandbox path is analogous to the "rw" >>> mount option. That is, it is mounted writeable, but says nothing about >>> which credentials can write to it. >>> >>>> And if we want to document it, what is our recommended >>>> solution in the doc? >>>> >>>> >>>> >>>> Regards, >>>> Qian Zhang >>>> >>>> On Fri, Apr 27, 2018 at 1:16 AM, James Peach wrote: >>>> >>>>> I commented on the doc, but at least some of the issues raised there I >>>>> would not regard as issues. Rather, they are about setting expectations >>>>> correctly and ensuring that we are documenting (and maybe enforcing) >>>>> sensible behavior. >>>>> >>>>> I'm not that keen on Mesos automatically "fixing" filesystem >>> permissions >>>>> and we should proceed down that path with caution, especially in the >>> ACLs >>>>> case. >>>>> >>>>>> On Apr 10, 2018, at 3:15 AM, Qian Zhang wrote: >>>>>> >>>>>> Hi Folks, >>>>>> >>>>>> I am working on MESOS-8767 to improve Mesos volume support regarding >>>>> volume ownership and permission, here is the design doc. Please feel >>> free >>>>> to let me know if you have any comments/feedbacks, you can reply this >>> mail >>>>> or comment on the design doc directly. Thanks! >>>>>> >>>>>> >>>>>> Regards, >>>>>> Qian Zhang >>>>> >>>>> >>> >>> >>
Re: Volume ownership and permission
Hi Folks, We found some issues for the solutions of this project and propose a better one, see here <https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE-v4KWwjmnCR0l8V4Tq2U/edit#heading=h.tjuy5xk67tuu> for details. Please let me know if you have any comments, thanks! Regards, Qian Zhang On Sat, Apr 28, 2018 at 7:57 AM, Qian Zhang wrote: > > The framework launched tasks in a group with different users? Sounds > like they dug their own hole :) > > So you mean we should actually put a best practice or limitation in doc: > when launching a task group with multiple tasks to share a SANDBOX volume > of PARENT type, all the tasks should be run with the same user, and that > user must be same with the user to launch the executor? Otherwise the task > will not be able to write to the volume. > > > I'd argue that the "rw" on the sandbox path is analogous to the "rw" > mount option. That is, it is mounted writeable, but says nothing about > which credentials can write to it. > > Can you please elaborate a bit on this? What would you suggest for the > "rw` volume mode? > > > Regards, > Qian Zhang > > On Fri, Apr 27, 2018 at 12:07 PM, James Peach wrote: > >> >> >> > On Apr 26, 2018, at 7:25 PM, Qian Zhang wrote: >> > >> > Hi James, >> > >> > Thanks for your comment! >> > >> > I think you are talking about the SANDBOX_PATH volume ownership issue >> > mentioned in the design doc >> > <https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE >> -v4KWwjmnCR0l8V4Tq2U/edit#heading=h.s6f8rmu65g2p>, >> > IIUC, you prefer to leaving it to framework, i.e., framework itself >> ought >> > to be able to handle such issue. But I am curious how framework can >> handle >> > it in such situation. If the framework launches a task group with >> different >> > users and with a SANDBOX_PATH volume of PARENT type, the tasks in the >> group >> > will definitely fail to write to the volume due to the ownership issue >> > though the volume's mode is set to "rw". So in this case, how should >> > framework handle it? >> >> The framework launched tasks in a group with different users? Sounds like >> they dug their own hole :) >> >> I'd argue that the "rw" on the sandbox path is analogous to the "rw" >> mount option. That is, it is mounted writeable, but says nothing about >> which credentials can write to it. >> >> > And if we want to document it, what is our recommended >> > solution in the doc? >> > >> > >> > >> > Regards, >> > Qian Zhang >> > >> > On Fri, Apr 27, 2018 at 1:16 AM, James Peach wrote: >> > >> >> I commented on the doc, but at least some of the issues raised there I >> >> would not regard as issues. Rather, they are about setting expectations >> >> correctly and ensuring that we are documenting (and maybe enforcing) >> >> sensible behavior. >> >> >> >> I'm not that keen on Mesos automatically "fixing" filesystem >> permissions >> >> and we should proceed down that path with caution, especially in the >> ACLs >> >> case. >> >> >> >>> On Apr 10, 2018, at 3:15 AM, Qian Zhang wrote: >> >>> >> >>> Hi Folks, >> >>> >> >>> I am working on MESOS-8767 to improve Mesos volume support regarding >> >> volume ownership and permission, here is the design doc. Please feel >> free >> >> to let me know if you have any comments/feedbacks, you can reply this >> mail >> >> or comment on the design doc directly. Thanks! >> >>> >> >>> >> >>> Regards, >> >>> Qian Zhang >> >> >> >> >> >> >
Re: Volume ownership and permission
> The framework launched tasks in a group with different users? Sounds like they dug their own hole :) So you mean we should actually put a best practice or limitation in doc: when launching a task group with multiple tasks to share a SANDBOX volume of PARENT type, all the tasks should be run with the same user, and that user must be same with the user to launch the executor? Otherwise the task will not be able to write to the volume. > I'd argue that the "rw" on the sandbox path is analogous to the "rw" mount option. That is, it is mounted writeable, but says nothing about which credentials can write to it. Can you please elaborate a bit on this? What would you suggest for the "rw` volume mode? Regards, Qian Zhang On Fri, Apr 27, 2018 at 12:07 PM, James Peach wrote: > > > > On Apr 26, 2018, at 7:25 PM, Qian Zhang wrote: > > > > Hi James, > > > > Thanks for your comment! > > > > I think you are talking about the SANDBOX_PATH volume ownership issue > > mentioned in the design doc > > <https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE- > v4KWwjmnCR0l8V4Tq2U/edit#heading=h.s6f8rmu65g2p>, > > IIUC, you prefer to leaving it to framework, i.e., framework itself ought > > to be able to handle such issue. But I am curious how framework can > handle > > it in such situation. If the framework launches a task group with > different > > users and with a SANDBOX_PATH volume of PARENT type, the tasks in the > group > > will definitely fail to write to the volume due to the ownership issue > > though the volume's mode is set to "rw". So in this case, how should > > framework handle it? > > The framework launched tasks in a group with different users? Sounds like > they dug their own hole :) > > I'd argue that the "rw" on the sandbox path is analogous to the "rw" mount > option. That is, it is mounted writeable, but says nothing about which > credentials can write to it. > > > And if we want to document it, what is our recommended > > solution in the doc? > > > > > > > > Regards, > > Qian Zhang > > > > On Fri, Apr 27, 2018 at 1:16 AM, James Peach wrote: > > > >> I commented on the doc, but at least some of the issues raised there I > >> would not regard as issues. Rather, they are about setting expectations > >> correctly and ensuring that we are documenting (and maybe enforcing) > >> sensible behavior. > >> > >> I'm not that keen on Mesos automatically "fixing" filesystem permissions > >> and we should proceed down that path with caution, especially in the > ACLs > >> case. > >> > >>> On Apr 10, 2018, at 3:15 AM, Qian Zhang wrote: > >>> > >>> Hi Folks, > >>> > >>> I am working on MESOS-8767 to improve Mesos volume support regarding > >> volume ownership and permission, here is the design doc. Please feel > free > >> to let me know if you have any comments/feedbacks, you can reply this > mail > >> or comment on the design doc directly. Thanks! > >>> > >>> > >>> Regards, > >>> Qian Zhang > >> > >> > >
Re: Volume ownership and permission
> On Apr 26, 2018, at 7:25 PM, Qian Zhang wrote: > > Hi James, > > Thanks for your comment! > > I think you are talking about the SANDBOX_PATH volume ownership issue > mentioned in the design doc > <https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE-v4KWwjmnCR0l8V4Tq2U/edit#heading=h.s6f8rmu65g2p>, > IIUC, you prefer to leaving it to framework, i.e., framework itself ought > to be able to handle such issue. But I am curious how framework can handle > it in such situation. If the framework launches a task group with different > users and with a SANDBOX_PATH volume of PARENT type, the tasks in the group > will definitely fail to write to the volume due to the ownership issue > though the volume's mode is set to "rw". So in this case, how should > framework handle it? The framework launched tasks in a group with different users? Sounds like they dug their own hole :) I'd argue that the "rw" on the sandbox path is analogous to the "rw" mount option. That is, it is mounted writeable, but says nothing about which credentials can write to it. > And if we want to document it, what is our recommended > solution in the doc? > > > > Regards, > Qian Zhang > > On Fri, Apr 27, 2018 at 1:16 AM, James Peach wrote: > >> I commented on the doc, but at least some of the issues raised there I >> would not regard as issues. Rather, they are about setting expectations >> correctly and ensuring that we are documenting (and maybe enforcing) >> sensible behavior. >> >> I'm not that keen on Mesos automatically "fixing" filesystem permissions >> and we should proceed down that path with caution, especially in the ACLs >> case. >> >>> On Apr 10, 2018, at 3:15 AM, Qian Zhang wrote: >>> >>> Hi Folks, >>> >>> I am working on MESOS-8767 to improve Mesos volume support regarding >> volume ownership and permission, here is the design doc. Please feel free >> to let me know if you have any comments/feedbacks, you can reply this mail >> or comment on the design doc directly. Thanks! >>> >>> >>> Regards, >>> Qian Zhang >> >>
Re: Volume ownership and permission
Hi James, Thanks for your comment! I think you are talking about the SANDBOX_PATH volume ownership issue mentioned in the design doc <https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE-v4KWwjmnCR0l8V4Tq2U/edit#heading=h.s6f8rmu65g2p>, IIUC, you prefer to leaving it to framework, i.e., framework itself ought to be able to handle such issue. But I am curious how framework can handle it in such situation. If the framework launches a task group with different users and with a SANDBOX_PATH volume of PARENT type, the tasks in the group will definitely fail to write to the volume due to the ownership issue though the volume's mode is set to "rw". So in this case, how should framework handle it? And if we want to document it, what is our recommended solution in the doc? Regards, Qian Zhang On Fri, Apr 27, 2018 at 1:16 AM, James Peach wrote: > I commented on the doc, but at least some of the issues raised there I > would not regard as issues. Rather, they are about setting expectations > correctly and ensuring that we are documenting (and maybe enforcing) > sensible behavior. > > I'm not that keen on Mesos automatically "fixing" filesystem permissions > and we should proceed down that path with caution, especially in the ACLs > case. > > > On Apr 10, 2018, at 3:15 AM, Qian Zhang wrote: > > > > Hi Folks, > > > > I am working on MESOS-8767 to improve Mesos volume support regarding > volume ownership and permission, here is the design doc. Please feel free > to let me know if you have any comments/feedbacks, you can reply this mail > or comment on the design doc directly. Thanks! > > > > > > Regards, > > Qian Zhang > >
Re: Volume ownership and permission
I commented on the doc, but at least some of the issues raised there I would not regard as issues. Rather, they are about setting expectations correctly and ensuring that we are documenting (and maybe enforcing) sensible behavior. I'm not that keen on Mesos automatically "fixing" filesystem permissions and we should proceed down that path with caution, especially in the ACLs case. > On Apr 10, 2018, at 3:15 AM, Qian Zhang wrote: > > Hi Folks, > > I am working on MESOS-8767 to improve Mesos volume support regarding volume > ownership and permission, here is the design doc. Please feel free to let me > know if you have any comments/feedbacks, you can reply this mail or comment > on the design doc directly. Thanks! > > > Regards, > Qian Zhang
Re: Volume ownership and permission
Hi Marc, I have shared the design doc to ensure anyone (no sign-in required) with the link can comment, can you try again? Regards, Qian Zhang On Tue, Apr 10, 2018 at 1:04 PM, Marc Roos wrote: > > Cannot access it > > > > -Original Message- > From: Qian Zhang [mailto:zhq527...@gmail.com] > Sent: dinsdag 10 april 2018 12:16 > To: mesos; user > Subject: Volume ownership and permission > > Hi Folks, > > I am working on MESOS-8767 > <https://issues.apache.org/jira/browse/MESOS-8767> to improve Mesos > volume support regarding volume ownership and permission, here is the > design doc <https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE- > v4KWwjmnCR0l8V4Tq2U/edit?usp=sharing> > . Please feel free to let me know if you have any comments/feedbacks, > you can reply this mail or comment on the design doc directly. Thanks! > > > Regards, > Qian Zhang > > >
Volume ownership and permission
Hi Folks, I am working on MESOS-8767 <https://issues.apache.org/jira/browse/MESOS-8767> to improve Mesos volume support regarding volume ownership and permission, here is the design doc <https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE-v4KWwjmnCR0l8V4Tq2U/edit?usp=sharing>. Please feel free to let me know if you have any comments/feedbacks, you can reply this mail or comment on the design doc directly. Thanks! Regards, Qian Zhang
