From: "J. Bruce Fields" <bfields@fieldses.org>
To: NeilBrown <neilb@suse.com>
Cc: "Andreas Gruenbacher" <agruenba@redhat.com>,
"Miklos Szeredi" <miklos@szeredi.hu>,
"Andreas Grünbacher" <andreas.gruenbacher@gmail.com>,
"Patrick Plagwitz" <Patrick_Plagwitz@web.de>,
"linux-unionfs@vger.kernel.org" <linux-unionfs@vger.kernel.org>,
"Linux NFS list" <linux-nfs@vger.kernel.org>,
"Linux FS-devel Mailing List" <linux-fsdevel@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir
Date: Fri, 10 May 2019 16:09:41 -0400 [thread overview]
Message-ID: <20190510200941.GB5349@fieldses.org> (raw)
In-Reply-To: <87woj3157p.fsf@notabene.neil.brown.name>
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.
--b.
>
> Do we have a vote? Or does someone make an executive decision??
>
> NeilBrown
next prev parent reply other threads:[~2019-05-10 20:09 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5a6862bd-924d-25e4-2a8e-ba4f51e66604@web.de>
2016-12-05 9:28 ` [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir Miklos Szeredi
2016-12-05 15:19 ` J. Bruce Fields
2016-12-05 15:36 ` Miklos Szeredi
2016-12-05 16:25 ` J. Bruce Fields
2016-12-05 18:25 ` Patrick Plagwitz
2016-12-05 19:37 ` Andreas Grünbacher
2016-12-05 22:58 ` Patrick Plagwitz
2016-12-05 23:19 ` Andreas Grünbacher
2016-12-05 23:24 ` Andreas Grünbacher
2016-12-06 10:08 ` Miklos Szeredi
2016-12-06 13:18 ` Andreas Gruenbacher
2016-12-06 18:58 ` J. Bruce Fields
2019-05-02 2:02 ` NeilBrown
2019-05-02 2:54 ` Amir Goldstein
2019-05-02 3:57 ` NeilBrown
2019-05-02 14:04 ` Andreas Gruenbacher
2019-05-02 14:28 ` Miklos Szeredi
2019-05-02 15:08 ` Andreas Grünbacher
2019-05-02 17:16 ` J. Bruce Fields
2019-05-02 17:53 ` Andreas Gruenbacher
2019-05-02 23:04 ` NeilBrown
2019-05-02 23:24 ` NeilBrown
2019-05-03 6:54 ` Andreas Grünbacher
2019-05-02 17:26 ` Goetz, Patrick G
2019-05-02 17:44 ` Andreas Gruenbacher
2019-05-02 17:51 ` Goetz, Patrick G
2019-05-03 15:27 ` J. Bruce Fields
2019-05-03 17:39 ` Goetz, Patrick G
2019-05-02 4:35 ` [PATCH] OVL: add honoracl=off mount option NeilBrown
2019-05-02 5:08 ` Randy Dunlap
2019-05-02 11:46 ` Amir Goldstein
2019-05-02 23:19 ` NeilBrown
2019-05-02 13:47 ` J. R. Okajima
2019-05-03 15:35 ` [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir J. Bruce Fields
2019-05-03 17:26 ` Amir Goldstein
2019-05-03 17:31 ` J. Bruce Fields
2019-05-03 17:41 ` Amir Goldstein
2019-05-03 17:51 ` Vivek Goyal
2019-05-07 0:24 ` NeilBrown
2019-05-10 20:09 ` J. Bruce Fields [this message]
2019-09-18 9:07 ` Miklos Szeredi
2019-09-18 19:49 ` J. Bruce Fields
2019-05-07 8:07 ` Miklos Szeredi
2019-05-07 23:51 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190510200941.GB5349@fieldses.org \
--to=bfields@fieldses.org \
--cc=Patrick_Plagwitz@web.de \
--cc=agruenba@redhat.com \
--cc=andreas.gruenbacher@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=neilb@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).