On Mon, Dec 5, 2016 at 4:19 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: >> Can NFS people comment on this? Where does the nfs4_acl come from? > > This is the interface the NFS client provides for applications to modify > NFSv4 ACLs on servers that support them. Fine, but why are we seeing this xattr on exports where no xattrs are set on the exported fs? >> What can overlayfs do if it's a non-empty ACL? > > As little as possible. You can't copy it up, can you? So any attempt > to support it is going to be incomplete. Right. > >> Does knfsd translate posix ACL into NFS acl? If so, we can translate >> back. Should we do a generic POSIX<->NFS acl translator? > > knsd does translate between POSIX and NFSv4 ACLs. It's a complicated This does explain the nfs4_acl xattr on the client. Question: if it's empty, why have it at all? > algorithm, and lossy (in the NFSv4->POSIX direction). The client > developers have been understandably reluctant to have anything to do > with it. > > So, I think listxattr should omit system.nfs4_acl, and attempts to > set/get the attribute should error out. The same should apply to any > "system." attribute not supported by both filesystems, I think? Basically that's what happens now. The problem is that nfsv4 mounts seem always have these xattrs, even when the exported fs doesn't have anything. We could do the copy up even if the NFS4->POSIX translation was possible (which is the case with POSIX ACL translated by knfsd). We'd just get back the original ACL, so that's OK. NFS is only supported as lower (read-only) layer, so we don't care about changing the ACL on the server. Thanks, Miklos -- 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
