Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir

[Miklos Szeredi <miklos@szeredi.hu>]

On Mon, Dec 5, 2016 at 4:19 PM, J. Bruce Fields <bfields@fieldses.org> 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