Re: nfs4_acl restricts copy_up in overlayfs

["bfields@fieldses.org" <bfields@fieldses.org>]

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.

Apologies if we've been through this before too, I've long ago paged out
any previous conversation....

> > The model for overlayfs and all unionfs should be that security is
> > enforced by the underlying filesystem _UNTIL_ the access mode is
> > modified on the top level filesystem.
> 
> How?
> 
> We've been through this.  We can't ask an NFS server exported
> read-only about what the permission to modify the filesystem would
> have been if it were exported read-write.  Sure, the protocol could be
> extended, etc, etc...  But it's just not a good fit.
> 
> >
> > IOW: if the user does a chmod, and that is authorised by the underlying
> > filesystem, then overlayfs is in charge of any further authorisation to
> > that file.
> > Adding richacls to that model means that you can attempt to copy the
> > ACL and allow the user to modify that instead of doing the chmod, but
> > the understanding should be that it's not the same ACL as was been
> > enforced by the server, so the copy up of the ACL should be treated as
> > a modification of the ACL (and should therefore first be subject to
> > authorisation by the server).
> 
> If someone adds the interface for access checking in the NFS client
> based on server sercurity model, but without actually having to do the
> request, and it works for read-only exports (which make a LOT of sense
> for the use cases where overlayfs may be used with NFS) then we can
> use that from overlayfs.  Last time Bruce looked this issue, he ran
> away screeming, IIRC.

In theory I suppose it's all possible, but I think the only practical
thing to do for now is just ignore NFSv4 ACLs.

--b.