linux-kernel - RE: A pass-through support for NFSv4 style ACL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <OSAPR01MB1843FD2B9710E89BDC1A72B3D97E9@OSAPR01MB1843.jpnprd01.prod.outlook.com>
Date:   Wed, 17 May 2023 09:29:02 +0000
From:   Ondrej Valousek <ondrej.valousek.xm@...esas.com>
To:     Christian Brauner <brauner@...nel.org>,
        Jeff Layton <jlayton@...nel.org>
CC:     "trondmy@...merspace.com" <trondmy@...merspace.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: A pass-through support for NFSv4 style ACL

Ok thanks guys for input.

I do not like richacl, too - for reasons mentioned here:
http://michael.orlitzky.com/articles/there_was_an_attempt_to_save_linux_filesystem_acls.xhtml
The "mask" hack in Posix ACLs and RichACLs is something that nobody really understands.
 I would (and not only me) like to have a clean NFSv4 acls implemented - just like Netapp, OmniOS, Solaris or FreeBSD.
The similarity with Windows ACLs is just another benefit. Yes there are small differences (mainly the OWNER@ and GROUP@ special principals there but I am sure it would be possible to resolve)

As per:
https://github.com/openzfs/zfs/issues/4966
I got impression the code on the ZFS is pretty much ready (including the XDR translation), but not sure if it's actually enforcing acls, probably not as it's task for VFS right?

Anyhow, pity that it's complicated to implement, it would be nice to have a functioning NFSv4 server with ACLs running on Linux.

Ondrej

-----Original Message-----
From: Christian Brauner <brauner@...nel.org> 
Sent: Mittwoch, 17. Mai 2023 09:43
To: Jeff Layton <jlayton@...nel.org>
Cc: Ondrej Valousek <ondrej.valousek.xm@...esas.com>; trondmy@...merspace.com; linux-fsdevel@...r.kernel.org; linux-kernel@...r.kernel.org
Subject: Re: A pass-through support for NFSv4 style ACL

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.