Re: nfs4_acl restricts copy_up in overlayfs

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

 



On 05/29/2018 10:01 PM, Trond Myklebust wrote:
> On Tue, 2018-05-29 at 20:08 -0500, Goldwyn Rodrigues wrote:
>>
>> 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.
>>
> 
> As I said, you are forking the security model. You are trying to make
> the NFS client act as a proxy for the NFS server without giving it
> enough information to do so.
> 
> The NFS client is careful to _always_ leave interpreting the ACL, mode,
> and other security information to the server. If it must try to act as
> a proxy for the server when serving up cached information, then it uses
> the ACCESS rpc call to ensure that it doesn't give up information that
> the server would normally deny to a particular user.

I am in agreement with the security model and that is what I want to
preserve. My question is if it is possible to detect that the security
can be represented by existing in-inode security features alone.

If it was up to me, I would not create the nfs4_acl xattr at the server
if it is not required and the security can be represented by existing
parameters, but it seems to be the protocol. To give a comparison, in
local filsystems, if "system.posix_acl" is not required it will not be
created.

> 
>> 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. 
> 
> If your server is a knfsd based Linux server, then maybe. If it's
> anything else, then the above statement is dead wrong. Either way,
> you'd be opening a large can of security worms by making those
> assumptions.

I agree. The man page says there are features (such as alarm and audit)
which are server dependent.

> 
>> However,
>> just because there is a nfs4_acl, a copy_up does not happen in the
>> client.
> 
> Which would appear to be the more secure behaviour if you are unable to
> enforce the exact same security semantics as the server.

I am not trying to override the security. I am trying to detect
duplication of security information. The common case of NFS
communication does not require the additional security parameters
(doesn't mean it is not required). So my question is: is it possible to
detect at the client that nfs4_acl is a duplicate of information which
can be and is represented by inode alone. If yes, can it be suppressed
by the client.

-- 
Goldwyn
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux