Re: nfs4_acl restricts copy_up in overlayfs

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

 




On 05/29/2018 04:37 PM, Trond Myklebust wrote:
> 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).
> 

The files permissions are checked during copy ups because a data copy
also happens in case of a change. The problem however is not the checks
have to happen for this operation but if we should bypass NFS security
for consequent ones.

For example, If we copy_up the file just because the current user is
able to, it would not copy the nfs4_acl. If there is a NFS4 acl rule to
DENY another user, the earlier denied user will be able to access the
file after the copy_up because we did not copy the nfs4_acl.

Overlayfs tries to make sure that all xattr from an underlying
filesystem is compatible with the one being copied to. nfs4_acl is not
compatible with a local filesystem it rejects the copy_up as EOPNOTSUPP.

>From the nfsd code (nfsd_get_nfs4_acl), in *most* cases nfs4_acl is just
a representation of i_mode and does not require a special ACL. However,
just because there is a nfs4_acl, a copy_up does not happen in the client.

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