Re: Volume ownership and permission

[James Peach]

> 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
> ,
> 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

[Qian Zhang]

Hi James,

Thanks for your comment!

I think you are talking about the SANDBOX_PATH volume ownership issue
mentioned in the design doc
,
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: Questions about secret handling in Mesos

[Vinod Kone]

We do direct protobuf to JSON conversion for our API endpoints and I don't
think we do any special case logic for `Secret` type in that conversion. So
`value` based secrets will have their value show up in v1 (and likely v0)
API endpoints.

On Mon, Apr 23, 2018 at 9:25 AM, Zhitao Li  wrote:

> Hi Alexander,
>
> We discovered that in our own testing thus do not plan to use the
> environment variable. For the `volume/secret` case, I believe it's possible
> to be careful enough so we do not log that, so it's more about whether we
> want to promise that.
>
> What do you think?
>
> On Mon, Apr 23, 2018 at 5:13 AM, Alexander Rojas 
> wrote:
>
>>
>> Hey Zhitao,
>>
>> I sadly have to tell you that the first assumption is not correct. If you
>> use environment based secrets, docker and verbose mode, they will get
>> printed (see this patch https://reviews.apache.org/r/57846/). The reason
>> is that the docker command will get logged and it might contain your
>> secrets. You may end up with some logging line like:
>>
>> ```
>> I0129 14:09:22.444318 docker.cpp:1139] Running docker -H
>> unix:///var/run/docker.suck run --cpu-shares 25 --memory 278435456 -e
>> ADMIN_PASSWORD=test_password …
>> ```
>>
>>
>> On 19. Apr 2018, at 19:57, Zhitao Li  wrote:
>>
>> Hello,
>>
>> We at Uber plan to use volume/secret isolator to send secrets from Uber
>> framework to Mesos agent.
>>
>> For this purpose, we are referring to these documents:
>>
>>- File based secrets design doc
>>
>> 
>>and slides
>>
>> 
>>.
>>- Apache Mesos secrets documentation
>>
>>
>> Could you please confirm that the following assumptions are correct?
>>
>>- Mesos agent and master will never log the secret data at any
>>logging level;
>>- Mesos agent and master will never expose the secret data as part of
>>any API response;
>>- Mesos agent and master will never store the secret in any
>>persistent storage, but only on tmpfs or ramfs;
>>- When the secret is first downloaded on the mesos agent, it will be
>>stored as "root" on the tmpfs/ramfs before being mounted in the container
>>ramfs.
>>
>> If above assumptions are true, then I would like to see them documented
>> in this as part of the Apache Mesos secrets documentation
>> . Otherwise, we'd
>> like to have a design discussion with maintainer of the isolator.
>>
>> We appreciate your help regarding this. Thanks!
>>
>> Regards,
>> Aditya And Zhitao
>>
>>
>>
>
>
> --
> Cheers,
>
> Zhitao Li
>

Re: Volume ownership and permission

[James Peach]

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