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 for Android: free password hash cracker in your pocket

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

Message-ID: <TYXPR01MB185439828CC7CEC40425065BD97C9@TYXPR01MB1854.jpnprd01.prod.outlook.com>
Date:   Fri, 19 May 2023 11:38:30 +0000
From:   Ondrej Valousek <ondrej.valousek.xm@...esas.com>
To:     Christian Brauner <brauner@...nel.org>,
        Theodore Ts'o <tytso@....edu>
CC:     Jeff Layton <jlayton@...nel.org>,
        "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

> 
> I'll note most of this complexity is only necessary if you want to 
> have local file access to the file system work with similar semantics 
> as what would get exported via NFSv4.  If you didn't, you could just 
> store the Windows-style ACL in an xattr and just let it be set via the 
> remote file system, and return it when the remote file system queries 
> it.  The problem comes when you want to have "RichACLs" actually 
> influence the local Linux permissions check.

> Yeah, I'm already scared enough.

Well I do not think it's that difficult. As I said, just take a look how OmniOS does things, very nice - you can set up a VM with it in just a half an hour and you get a system with ZFS and native NFSv4 working.
True it's not Richacl, but just NFSv4 style acl - even better.

As for the implementation, lot of code could be presumably taken from Samba which is already doing Windows style-ACL to NFSv4 translation.

To me interesting bit was that the original path from Andreas was not accepted largely because it would add another piece of mess to the already messy code in the kernel, I did not know that.
I hoped that  now that Christian cleaned the code recently, it would perhaps allow us to reconsider things, but maybe I am too naive here 😊