Re: nfs4_acl restricts copy_up in overlayfs

[Miklos Szeredi <miklos@szeredi.hu>]

On Thu, May 31, 2018 at 4:06 PM, bfields@fieldses.org
<bfields@fieldses.org> wrote:
> On Thu, May 31, 2018 at 03:30:04PM +0200, Miklos Szeredi wrote:
>> On Thu, May 31, 2018 at 3:10 PM, Trond Myklebust
>> <trondmy@hammerspace.com> wrote:
>> > On Thu, 2018-05-31 at 14:55 +0200, Miklos Szeredi wrote:
>> >> On Thu, May 31, 2018 at 2:47 PM, Trond Myklebust <trondmy@hammerspace.com> wrote:
>> >> > I'm still in strong disagreement with the model you are presenting
>> >> > here. It is a client enforced model, which is not ever going to be
>> >> > compatible with the NFS model.
>> >>
>> >> It's the only sane model that overlayfs can do.
>> >>
>> >> Think of it this way:  creating an image file on NFS, formating it to
>> >> ext4 and mounting it locally through the loop device is not going to
>> >> be compatible with the NFS security model either.  Should we care?
>> >
>> > Yes you should care because you are proposing that the simple act of
>> > mounting through overlayfs will change who can access, read and modify
>> > existing files from a NFS server.
>>
>> Only access/read: NFS can only be read-only layer.  So it's impossible
>> to actually modify a file on NFS through overlayfs.
>
> In addition to being read-only, I assume it's also unchanging?  I wonder
> why you'd want to use NFS at all for this case--sharing a read-only
> ext4-formatted block device would seem more straightforward.

Actually we could allow changes on the server side.   Overlayfs sort
of does this already (calls underlying fs's ->d_revalidate() from
ovl_dentry_revalidate()).  What's still needed is to detect rename by
rechecking parent and d_name to match overlay dentry's parent and
d_name.

But a shared block dev could be used in most cases, I guess.

Thanks,
Miklos