[PATCH v4 04/30] fs: add new get acl method

[Christian Brauner]

On Thu, Oct 06, 2022 at 08:31:47AM +0200, Miklos Szeredi wrote:
> On Wed, 5 Oct 2022 at 09:15, Christian Brauner <brauner at kernel.org> wrote:
> 
> > We're just talking about thet fact that
> > {g,s}etxattr(system.posix_acl_{access,default}) work on cifs but
> > getting acls based on inode operations isn't supported. Consequently you
> > can't use the acls for permission checking in the vfs for cifs. If as
> > you say below that's intentional because the client doesn't perform
> > access checks then that's probably fine.
> 
> Now I just need to wrap my head around how this interacts with all the
> uid/gid transformations.

Currently it doesn't because cifs doesn't support idmapped mounts.

> 
> Do these (userns, mnt_userns) even make sense for the case of remotely
> checked permissions?

Namespaces are local concepts. They are relevant for permission checking
and are e.g., used to generate a {g,u}id that may be sent to a server. A
concrete example would be a network filesystems that would change the
ownership of a file and the client calls it's ->setattr() inode
operation. The fs_userns and/or mnt_userns is used to generate a raw
{g,u}id value to be sent to the server (So all netns call from_kuid()
ultimately to send a raw {g,u}id over the wire. The server can then do
whatever additional permission checking it wants based on that {g,u}id.

For acls it's the same. We use the namespaces to generate the raw values
and send them to the server that stores them. Either in the acl uapi
format or if the netfs has a custom format for acls or translate them
into it's own acl format. The server can then use them for permission
checking however it wants. But if the server allows the client to
retrieve them during permission checking in the vfs then we need to
translate that raw format from the server into the proper local format
again at which point the namespaces are relevant again.
I hope that helped.