[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190918090731.GB19549@miu.piliscsaba.redhat.com>
Date: Wed, 18 Sep 2019 11:07:31 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: "J. Bruce Fields" <bfields@...ldses.org>
Cc: NeilBrown <neilb@...e.com>,
Andreas Gruenbacher <agruenba@...hat.com>,
Andreas Grünbacher
<andreas.gruenbacher@...il.com>,
Patrick Plagwitz <Patrick_Plagwitz@....de>,
"linux-unionfs@...r.kernel.org" <linux-unionfs@...r.kernel.org>,
Linux NFS list <linux-nfs@...r.kernel.org>,
Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Lange <lange@...ormatik.uni-koeln.de>
Subject: Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir
On Fri, May 10, 2019 at 04:09:41PM -0400, J. Bruce Fields wrote:
> On Tue, May 07, 2019 at 10:24:58AM +1000, NeilBrown wrote:
> > Interesting perspective .... though doesn't NFSv4 explicitly allow
> > client-side ACL enforcement in the case of delegations?
>
> Not really. What you're probably thinking of is the single ACE that the
> server can return on granting a delegation, that tells the client it can
> skip the ACCESS check for users matching that ACE. It's unclear how
> useful that is. It's currently unused by the Linux client and server.
>
> > Not sure how relevant that is....
> >
> > It seems to me we have two options:
> > 1/ declare the NFSv4 doesn't work as a lower layer for overlayfs and
> > recommend people use NFSv3, or
> > 2/ Modify overlayfs to work with NFSv4 by ignoring nfsv4 ACLs either
> > 2a/ always - and ignore all other acls and probably all system. xattrs,
> > or
> > 2b/ based on a mount option that might be
> > 2bi/ general "noacl" or might be
> > 2bii/ explicit "noxattr=system.nfs4acl"
> >
> > I think that continuing to discuss the miniature of the options isn't
> > going to help. No solution is perfect - we just need to clearly
> > document the implications of whatever we come up with.
> >
> > I lean towards 2a, but I be happy with with any '2' and '1' won't kill
> > me.
>
> I guess I'd also lean towards 2a.
>
> I don't think it applies to posix acls, as overlayfs is capable of
> copying those up and evaluating them on its own.
POSIX acls are evaluated and copied up.
I guess same goes for "security.*" attributes, that are evaluated on MAC checks.
I think it would be safe to ignore failure to copy up anything else. That seems
a bit saner than just blacklisting nfs4_acl...
Something like the following untested patch.
Thanks,
Miklos
---
fs/overlayfs/copy_up.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -36,6 +36,13 @@ static int ovl_ccup_get(char *buf, const
module_param_call(check_copy_up, ovl_ccup_set, ovl_ccup_get, NULL, 0644);
MODULE_PARM_DESC(check_copy_up, "Obsolete; does nothing");
+static bool ovl_must_copy_xattr(const char *name)
+{
+ return !strcmp(name, XATTR_POSIX_ACL_ACCESS) ||
+ !strcmp(name, XATTR_POSIX_ACL_DEFAULT) ||
+ !strncmp(name, XATTR_SECURITY_PREFIX, XATTR_SECURITY_PREFIX_LEN);
+}
+
int ovl_copy_xattr(struct dentry *old, struct dentry *new)
{
ssize_t list_size, size, value_size = 0;
@@ -107,8 +114,13 @@ int ovl_copy_xattr(struct dentry *old, s
continue; /* Discard */
}
error = vfs_setxattr(new, name, value, size, 0);
- if (error)
- break;
+ if (error) {
+ if (ovl_must_copy_xattr(name))
+ break;
+
+ /* Ignore failure to copy unknown xattrs */
+ error = 0;
+ }
}
kfree(value);
out:
Powered by blists - more mailing lists