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

["Andreas Grünbacher" <andreas.gruenbacher@gmail.com>]

2016-12-05 23:58 GMT+01:00 Patrick Plagwitz <Patrick_Plagwitz@web.de>:
> On 12/05/2016 08:37 PM, Andreas Gr=C3=BCnbacher wrote:
>> 2016-12-05 17:25 GMT+01:00 J. Bruce Fields <bfields@fieldses.org>:
>>> On Mon, Dec 05, 2016 at 04:36:03PM +0100, Miklos Szeredi wrote:
>>>> 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 mod=
ify
>>>>> 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?
>>>
>>> I don't know.  I took another look at the original patch and don't see
>>> any details on the server setup: which server is it (knfsd, ganesha,
>>> netapp, ...)?  How is it configured?
>>>
>>>>>> 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 attemp=
t
>>>>> to support it is going to be incomplete.
>>>>
>>>> Right.
>>>>
>>>>>
>>>>>> Does knfsd translate posix ACL into NFS acl?  If so, we can translat=
e
>>>>>> 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?
>>>
>>> I'm honestly not sure what's going on there.  I'd be curious to see a
>>> network trace if possible.
>>
>> I do see "system.nfs4_acl" attributes on knfsd exported filesystems
>> that support POSIX ACLs (for ext4: "mount -o acl"). For exported
>> filesystem that don't support POSIX ACLs (ext4: mount -o noacl), that
>> attribute is missing. The attribute shouldn't be empty though; when
>> the file has no real ACL, "system.nfs4_acl" represents the file mode
>> permissions. The "system.nfs4_acl" attribute exposes the information
>> on the wire; there is no resonable way to translate that into an ACL
>> on another filesystem, really.
>>
>> Patrick, what does 'getfattr -m- -d /nfs/file' give you?
>>
> getfattr -m - -d nfs/folder -e text gives
>
> # file: nfs/folder/
> system.nfs4_acl=3D"\000\000\000^C\000\000\000\000\000\000\000\000\000^V^A=
<E7>\000\000\000^FOWNER@\000\000\000\000\000\000\000\000\000\000\000^R\000<=
A1>\000\000\000^FGROUP@\000\000\000\000\000\000\000\000\000\000\000^R\000<A=
1>\000\000\000
>     EVERYONE@\000\000"
>
> Those are 80 bytes. I checked again and vfs_getxattr indeed returns size=
=3D80.
> It just looked empty because the first byte is 0... Ok, so nfs4_acl is no=
t
> empty after all and checking *value =3D=3D 0 does not tell if there are a=
ctually
> ACLs present or not, sorry for the confusion.
>
> You are right, when I mount the exported fs with noacl the problem goes a=
way.
> You already helped me there, thanks.
>
> Still, I think there should be a way to copy up files that actually have =
no
> ACLs since acl is often the default for ext4 mounts and giving an "Operat=
ion
> not supported" for random open(2)s is not a very good way to convey what'=
s
> going on.

It's not hard to come up with a heuristic that determines if a
system.nfs4_acl value is equivalent to a file mode, and to ignore the
attribute in that case. (The file mode is transmitted in its own
attribute already, so actually converting .) That way, overlayfs could
still fail copying up files that have an actual ACL. It's still an
ugly hack ...

Andreas