On 05/31/2018 09:06 AM, bfields@xxxxxxxxxxxx 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
