linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: Ondrej Valousek <ondrej.valousek.xm@renesas.com>,
	"trondmy@hammerspace.com" <trondmy@hammerspace.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: A pass-through support for NFSv4 style ACL
Date: Wed, 17 May 2023 09:42:59 +0200	[thread overview]
Message-ID: <20230517-herstellen-zitat-21eeccd36558@brauner> (raw)
In-Reply-To: <cc4317d9cb8f10aa0b3750bdb6db8b4e77ff26f8.camel@kernel.org>

On Tue, May 16, 2023 at 05:22:30PM -0400, Jeff Layton wrote:
> On Tue, 2023-05-16 at 20:50 +0000, Ondrej Valousek wrote:
> > 
> > Hi Christian,
> > 
> > Would it be possible to patch kernel the way it accepts native (i.e no
> > conversion to Posix ACL) NFSv4 style ACLs for filesystems that can
> > support them?
> > I.E. OpenZFS, NTFS, could be also interesting for Microsofts WSL2  or
> > Samba right?
> > 
> > I mean, I am not trying to push richacl again knowing they have been
> > rejected, but just NFS4 style Acls as they are so similar to Windows
> > ACLs.
> > 
> 
> Erm, except you kind of are if you want to do this. I don't see how this
> idea works unless you resurrect RichACLs or something like them.

I have no idea about the original flame war that ended RichACLs in
additition to having no clear clue what RichACLs are supposed to
achieve. My current knowledge extends to "Christoph didn't like them".

> 
> > The idea here would be that we could
> > - mount NTFS/ZFS filesystem and inspect ACLs using existing tools
> > (nfs4_getacl)
> > - share with NFSv4 in a pass through mode
> > - in Windows WSL2 we could inspect local filesystem ACLs using the
> > same tools
> > 
> > Does it make any sense or it would require lot of changes to VFS
> > subsystem or its a nonsense altogether?

Yes, very likely.

We'd either have to change the current inode operations for getting and
setting acls to take a new struct acl that can contain either posix acls
or rich acls or add new ones just for these new fangled ones.

Choosing the first - more sensible - of these two options will mean
updating each filesystem's acl inode operations. Might turn out to not
be invasive code as it might boil down to struct posix_acl *acl =
acl->posix at the beginning of each method but still.

Then we'd probably also need to:

* handle permission checking (see Jeff's comment below)
* change/update the ACL caching layer
* if the past hast taught me anything then overlayfs would probably need
  some additional logic as well

> > 
> 
> Eventually you have to actually enforce the ACL. Do NTFS/ZFS already
> have code to do this? If not then someone would need to write it.
> 
> Also windows and nfs acls do have some differences, so you'll need a
> translation layer too.

Jeff, I know you have some knowledge in this area you probably are
better equipped to judge the sanity and feasibility of this.

  reply	other threads:[~2023-05-17  7:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-16 12:46 [PATCH] fs: don't call posix_acl_listxattr in generic_listxattr Jeff Layton
2023-05-16 14:17 ` Christian Brauner
     [not found]   ` <TYXPR01MB18549D3A5B0BE777D7F6B284D9799@TYXPR01MB1854.jpnprd01.prod.outlook.com>
2023-05-16 21:22     ` A pass-through support for NFSv4 style ACL Jeff Layton
2023-05-17  7:42       ` Christian Brauner [this message]
2023-05-17  7:45         ` Christoph Hellwig
2023-05-17  7:50           ` Christian Brauner
2023-05-17  9:29         ` Ondrej Valousek
2023-05-17  9:58         ` Jeff Layton
2023-05-17 12:39         ` Theodore Ts'o
2023-05-19 10:56           ` Christian Brauner
2023-05-19 11:38             ` Ondrej Valousek
2023-05-19 12:02               ` Christian Brauner
2023-09-04 20:36 ` [PATCH] fs: don't call posix_acl_listxattr in generic_listxattr Ondrej Valousek
2023-09-05 10:50   ` Jeff Layton
2023-09-05 11:36     ` Ondrej Valousek

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=20230517-herstellen-zitat-21eeccd36558@brauner \
    --to=brauner@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ondrej.valousek.xm@renesas.com \
    --cc=trondmy@hammerspace.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).