On Fri, May 18, 2018 at 12:30 AM, Goldwyn Rodrigues <rgoldwyn@xxxxxxx> wrote: > > > On 05/17/2018 02:26 PM, Vivek Goyal wrote: >> On Mon, Apr 16, 2018 at 09:35:25AM -0500, Goldwyn Rodrigues wrote: >>> From: Fabian Vogt <fvogt@xxxxxxxx> >>> >>> xattrs are not guarantees to be compatible across different filesystems. >>> Operations which lead to copying of files to the upper layer fail with an >>> "Operation not supported" error from the filesystem if a xattr could not be >>> written in the upper layer. We can safely ignore "system" xattrs. >>> >>> One easy to hit example is using NFS as a read-only lower layer and !NFS as >>> upper layer to store changes. Files on NFS can have the "system.nfs4_acl" >> >> I don't know much about nfs4_acl. But name suggests that it stored ACLs >> there. So if we ignore these over copy up, does that mean we are not >> enforcing ACL policy over copy up. So say some user which was not able >> to read a file when it was on lower, might be able to read it after >> copy up? >> >> Or I have completely misunderstood it? >> >> > > As far as I know, all "system" attributes are filesystem specific (even > if they are the same fstype) and cannot be comprehended by other > filesystems. Hence, they can be ignored. > > Unfortunately, system.nfs4_acl is a part of protocol and is null most of > the times. > > Here is an earlier discussion I found which did not conclude: > https://www.spinics.net/lists/linux-nfs/msg61045.html It did have a conclusion, except nobody done anything in that direction: In certain cases nfs4_acl represents the same permissions as file mode. This case can be detected and the nfs4_acl xattr ignored. As a first step that's definitely something that could help in most cases. I'd be reluctant to just ignore copy up errors on system xattrs generally. 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
