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>
Subject: Re: [PATCH] fix NFSv4 acl detection on F39
Date: Mon, 15 May 2023 13:11:26 -0400 [thread overview]
Message-ID: <fb005d7e29f1167b83acf7b10800ff3124ee2a50.camel@redhat.com> (raw)
In-Reply-To: <TYXPR01MB18547A591663A4934B5D4D82D9789@TYXPR01MB1854.jpnprd01.prod.outlook.com>
On Mon, 2023-05-15 at 11:50 +0000, Ondrej Valousek wrote:
> Hi Paul,
>
> Ok first of all, thanks for taking initiative on this, I am unable to proceed on this on my own at the moment.
> I see few problems with this:
>
> 1. The calculation of the 'listbufsize' is incorrect in your patch. It will _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 ACL on NFSv4 filesystem. Digging further it seems that kernel in F39 behaves differently to the previous kernels:
>
> F38:
> # getfattr -m . /path_to_nfs4_file
> # file: path_to_nfs4_file
> system.nfs4_acl <---- only single xattr 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
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.
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.
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.
Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
>
> Now I faintly recall there was an activity in to move POSIX acls calculation from userspace to kernel (now Jeff in CC will hopefully clarify this)
>
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.
--
Jeff Layton <jlayton@redhat.com>
next parent reply other threads:[~2023-05-15 17:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230501194321.57983-1-ondrej.valousek.xm@renesas.com>
[not found] ` <c955ee20-371c-5dde-fcb5-26d573f69cd9@cs.ucla.edu>
[not found] ` <TYXPR01MB1854B3C3B8215DD0FA7B83CCD96D9@TYXPR01MB1854.jpnprd01.prod.outlook.com>
[not found] ` <17355394.lhrHg4fidi@nimes>
[not found] ` <32edbaf1-d3b1-6057-aefc-d83df3266c20@cs.ucla.edu>
[not found] ` <4f1519d8-bda1-1b15-4a78-a8072ba1551a@cs.ucla.edu>
[not found] ` <TYXPR01MB18547A591663A4934B5D4D82D9789@TYXPR01MB1854.jpnprd01.prod.outlook.com>
2023-05-15 17:11 ` Jeff Layton [this message]
2023-05-15 17:28 ` [PATCH] fix NFSv4 acl detection on F39 Trond Myklebust
2023-05-15 17:49 ` Jeff Layton
2023-05-15 18:53 ` Trond Myklebust
2023-05-16 9:17 ` Christian Brauner
2023-05-16 12:20 ` Jeff Layton
2023-05-16 12:29 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fb005d7e29f1167b83acf7b10800ff3124ee2a50.camel@redhat.com \
--to=jlayton@redhat.com \
--cc=brauner@kernel.org \
--cc=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=ondrej.valousek.xm@renesas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).