Re: nfs4_acl restricts copy_up in overlayfs

[Goldwyn Rodrigues <rgoldwyn@suse.de>]

On 05/31/2018 09:06 AM, 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:
>>>
>>> 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.
> 

Ignoring nfs4_acl will override the NFS security model where a user
which is specifically denied read access in the nfs4_acl will get read
access if another user who is allowed to read/write edits the file.

I would agree ignoring NFS4 ACLs is the best option.


-- 
Goldwyn