Re: A pass-through support for NFSv4 style ACL

[Christian Brauner <brauner@kernel.org>]

On Fri, May 19, 2023 at 11:38:30AM +0000, Ondrej Valousek wrote:
> > 
> > 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 😊

Noo one is going to stop you from writing the code and posting it on the
list. But I think none of us here will be very eager to implement it. If
it can be done cleanly without performance regressions or unwiedly
complications in the generic lookup and permission checking code and
both posix acls and these nfs4 style acls can be abstracted away nicely
in a single file, and have well-defined semantics and there's a clear
use-case that isn't just someone's hobby project then it might be
considered. But it might also mean you've spent significant effort just
to hear a no in the end.