Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <fb005d7e29f1167b83acf7b10800ff3124ee2a50.camel@redhat.com>
Subject: Re: [PATCH] fix NFSv4 acl detection on F39
From:   Jeff Layton <jlayton@redhat.com>
To:     Ondrej Valousek <ondrej.valousek.xm@renesas.com>,
        Paul Eggert <eggert@cs.ucla.edu>,
        Bruno Haible <bruno@clisp.org>,
        Christian Brauner <brauner@kernel.org>
Cc:     "bug-gnulib@gnu.org" <bug-gnulib@gnu.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        linux-nfs <linux-nfs@vger.kernel.org>
Date:   Mon, 15 May 2023 13:11:26 -0400
In-Reply-To: <TYXPR01MB18547A591663A4934B5D4D82D9789@TYXPR01MB1854.jpnprd01.prod.outlook.com>
References: <20230501194321.57983-1-ondrej.valousek.xm@renesas.com>
         <c955ee20-371c-5dde-fcb5-26d573f69cd9@cs.ucla.edu>
         <TYXPR01MB1854B3C3B8215DD0FA7B83CCD96D9@TYXPR01MB1854.jpnprd01.prod.outlook.com>
         <17355394.lhrHg4fidi@nimes>
         <32edbaf1-d3b1-6057-aefc-d83df3266c20@cs.ucla.edu>
         <4f1519d8-bda1-1b15-4a78-a8072ba1551a@cs.ucla.edu>
         <TYXPR01MB18547A591663A4934B5D4D82D9789@TYXPR01MB1854.jpnprd01.prod.outlook.com>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.1 (3.48.1-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

On Mon, 2023-05-15 at 11:50 +0000, Ondrej Valousek wrote:
> Hi Paul,
>=20
> Ok first of all, thanks for taking initiative on this, I am unable to pro=
ceed on this on my own at the moment.
> I see few problems with this:
>=20
> 1. The calculation of the 'listbufsize' is incorrect in your patch. It wi=
ll _not_work as you expected and won't limit the number of syscalls (which =
is why we came up with this patch, right?). Check with my original proposal=
, we really need to check for 'system.nfs4' xattr name presence here
> 2. It mistakenly detects an ACL presence on files which do not have any A=
CL on NFSv4 filesystem. Digging further it seems that kernel in F39 behaves=
 differently to the previous kernels:
>=20
> F38:=20
> # getfattr -m . /path_to_nfs4_file
> # file: path_to_nfs4_file
> system.nfs4_acl                                    <---- only single xatt=
r detected
>
> F39:
> # getfattr -m . /path_to_nfs4_file
> # file: path_to_nfs4_file
> system.nfs4_acl
> system.posix_acl_default
> /* SOMETIMES even shows this */
> system.posix_acl_default

(cc'ing Christian and relevant kernel lists)

I assume the F39 kernel is v6.4-rc based? If so, then I think that's a
regression. NFSv4 client inodes should _not_ report a POSIX ACL
attribute since the protocol doesn't support them.

In fact, I think the rationale in the kernel commit below is wrong.
NFSv4 has a listxattr operation, but doesn't support POSIX ACLs.

Christian, do we need to revert this?

commit e499214ce3ef50c50522719e753a1ffc928c2ec1
Author: Christian Brauner <brauner@kernel.org>
Date:   Wed Feb 1 14:15:01 2023 +0100

    acl: don't depend on IOP_XATTR
   =20
    All codepaths that don't want to implement POSIX ACLs should simply not
    implement the associated inode operations instead of relying on
    IOP_XATTR. That's the case for all filesystems today.
   =20
    For vfs_listxattr() all filesystems that explicitly turn of xattrs for =
a
    given inode all set inode->i_op to a dedicated set of inode operations
    that doesn't implement ->listxattr().  We can remove the dependency of
    vfs_listxattr() on IOP_XATTR.
   =20
    Removing this dependency will allow us to decouple POSIX ACLs from
    IOP_XATTR and they can still be listed even if no other xattr handlers
    are implemented. Otherwise we would have to implement elaborate schemes
    to raise IOP_XATTR even if sb->s_xattr is set to NULL.
   =20
    Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>


>=20
> Now I faintly recall there was an activity in to move POSIX acls calculat=
ion from userspace to kernel (now Jeff in CC will hopefully clarify this)
>=20

The POSIX<->NFSv4 ACL translation has always been in the kernel server.
It has to be, as the primary purpose is to translate v4 ACLs from the
clients to and from the POSIX ACLs that the exported Linux filesystems
support.

--=20
Jeff Layton <jlayton@redhat.com>