nfs4_acl restricts copy_up in overlayfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



While mounting overlayfs with NFS as a lower directory and a local
filesystem as an upper layer leads to copy_up failures because NFS4 has
an extra system.nfs4_acl which cannot be copied up. This has been
discussed before [1] and [2] with the suggestion that nfs4_acl is
derived from posix_acls or just inode->i_mode *most* of the times and
hence it can be mapped back.

The problem is NFS client knows nothing about nfs4_acl and it is decoded
in nfs4-acl-tools. Even if we make nfs client capable of understand
nfs4_acl xattr, can it be used to perform ACL's for the system. AFAIU,
it is uses user/group names as opposed uid/gid to perform id mapping.
Can the client map it back to user names and derive if it is just an
replica of inode's i_mode?

The idea is to suppress nfs4_acl if it is the same as inode's i_mode.
This means nfs4-acl-tools/nfs4_getacl would give no results when
requesting for ACLs. This would break existing applications if they
expect some output from nfs4_getfacl.

Is there a better way to identify if nfs4_acl is just a representation
of i_mode at the client end and can be safely ignored during an
overlayfs copy_up? Can we include a flag for this?


[1] https://www.spinics.net/lists/linux-nfs/msg61045.html
[2] https://www.spinics.net/lists/linux-unionfs/msg04736.html

-- 
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



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux