Re: nfs4_acl restricts copy_up in overlayfs

[Trond Myklebust <trondmy@hammerspace.com>]

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.

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

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

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com