This sets SB_POSIXACL only if ACL support is really enabled, instead of always setting SB_POSIXACL if the NFS protocol version theoretically supports ACL.
The code comment says "We will [apply the umask] ourselves", but that happens in posix_acl_create() only if the kernel has POSIX ACL support. Without it, posix_acl_create() is an empty dummy function.
So let's not pretend we will apply the umask if we can already know that we will never.
This fixes a problem where the umask is always ignored in the NFS client when compiled without CONFIG_FS_POSIX_ACL. This is a 4 year old regression caused by commit 013cdf1088d723 which itself was not completely wrong, but failed to consider all the side effects by misdesigned VFS code.
Reviewed-by: J. Bruce Fields bfields@redhat.com Cc: stable@vger.kernel.org Signed-off-by: Max Kellermann max.kellermann@ionos.com --- fs/nfs/super.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/super.c b/fs/nfs/super.c index 0d6473cb00cb..051986b422b0 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -1064,14 +1064,19 @@ static void nfs_fill_super(struct super_block *sb, struct nfs_fs_context *ctx) * The VFS shouldn't apply the umask to mode bits. * We will do so ourselves when necessary. */ - sb->s_flags |= SB_POSIXACL; + if (NFS_SB(sb)->caps & NFS_CAP_ACLS) { + sb->s_flags |= SB_POSIXACL; + } + sb->s_time_gran = 1; sb->s_time_min = 0; sb->s_time_max = U32_MAX; sb->s_export_op = &nfs_export_ops; break; case 4: - sb->s_flags |= SB_POSIXACL; + if (NFS_SB(sb)->caps & NFS_CAP_ACLS) { + sb->s_flags |= SB_POSIXACL; + } sb->s_time_gran = 1; sb->s_time_min = S64_MIN; sb->s_time_max = S64_MAX;
On Tue, 2023-09-19 at 10:18 +0200, Max Kellermann wrote:
This sets SB_POSIXACL only if ACL support is really enabled, instead of always setting SB_POSIXACL if the NFS protocol version theoretically supports ACL.
The code comment says "We will [apply the umask] ourselves", but that happens in posix_acl_create() only if the kernel has POSIX ACL support. Without it, posix_acl_create() is an empty dummy function.
So let's not pretend we will apply the umask if we can already know that we will never.
This fixes a problem where the umask is always ignored in the NFS client when compiled without CONFIG_FS_POSIX_ACL. This is a 4 year old regression caused by commit 013cdf1088d723 which itself was not completely wrong, but failed to consider all the side effects by misdesigned VFS code.
A little more than 4 years now!
Reviewed-by: J. Bruce Fields bfields@redhat.com Cc: stable@vger.kernel.org Signed-off-by: Max Kellermann max.kellermann@ionos.com
fs/nfs/super.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/super.c b/fs/nfs/super.c index 0d6473cb00cb..051986b422b0 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -1064,14 +1064,19 @@ static void nfs_fill_super(struct super_block *sb, struct nfs_fs_context *ctx) * The VFS shouldn't apply the umask to mode bits. * We will do so ourselves when necessary. */
sb->s_flags |= SB_POSIXACL;
if (NFS_SB(sb)->caps & NFS_CAP_ACLS) {
sb->s_flags |= SB_POSIXACL;
}
nit: curly braces aren't needed here
sb->s_time_gran = 1; sb->s_time_min = 0; sb->s_time_max = U32_MAX; sb->s_export_op = &nfs_export_ops; break;
case 4:
sb->s_flags |= SB_POSIXACL;
if (NFS_SB(sb)->caps & NFS_CAP_ACLS) {
sb->s_flags |= SB_POSIXACL;
sb->s_time_gran = 1; sb->s_time_min = S64_MIN; sb->s_time_max = S64_MAX;}
(cc'ing Christian)
This patch may have a minor conflict with this patch:
https://lore.kernel.org/linux-nfs/20230911-acl-fix-v3-1-b25315333f6c@kernel....
...but it seems like the right thing to do if POSIX ACLs are compiled out.
Reviewed-by: Jeff Layton jlayton@kernel.org
linux-stable-mirror@lists.linaro.org