On Tue, 2018-05-29 at 15:32 -0500, Goldwyn Rodrigues wrote: > 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 > If the permissions are unchanged so that overlayfs is not trying to override the way the server interprets the ACL, and credential held by the user, then you are better off calling the Linux client for open/close and permissions calls. Once you've allowed the user to chmod or chown the file, you are on your own, because your security model for the file will have forked with the security model provided by NFS. At that point, the file had better have been copied up, and you'd better be ready to manage it entirely from overlayfs. The above applies not only when the file is subject to NFSv4 acls, but it is also true when you are using strong authentication (i.e. Kerberos V). -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx ��.n��������+%������w��{.n�����{���w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
