mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Qian Zhang <zhq527...@gmail.com>
Subject Re: Volume ownership and permission
Date Fri, 27 Apr 2018 23:57:01 GMT
> 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 <jorgar@gmail.com> wrote:

>
>
> > On Apr 26, 2018, at 7:25 PM, Qian Zhang <zhq527725@gmail.com> 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 <jpeach@apache.org> 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 <zhq527725@gmail.com> 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
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message