Message ID | 20230919081844.1096767-1-max.kellermann@ionos.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp3492463vqi; Tue, 19 Sep 2023 08:54:50 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGxalMqPB28Qf2ODZfZotpXB6wGe5vc0DVPyZM8/TTaaD6ZOlRCMxqKRn2VxyM9WysajNKU X-Received: by 2002:a05:6a20:7348:b0:13c:ca8b:7e29 with SMTP id v8-20020a056a20734800b0013cca8b7e29mr10601208pzc.12.1695138890236; Tue, 19 Sep 2023 08:54:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695138890; cv=none; d=google.com; s=arc-20160816; b=aSy9+g0/U9bTPEdTSe0SqlLGfX0h+8imj/Hji+GJ+QK6IPUSBNzmrLmVFUPxbT6Lfw DAp2HMHnPc2r775j3JKIQYAPvlyOjOA/rpkM7Q8eVSXZITglB9XBAOIlYyra1xmfXKu8 iW7Y5bHgrfljx3TnJyZnlpNL/zYgoZVqKRQk+u7DXz7rZK8Z6Vb54CwzrFltZV7wl6nF omdiqgAfyzRLyuXP+H0DIqNG1gV2NdRthwUreML+bGuL2b8QtUkg1rO0wb3yf5tNcOsH 9GnLQ6ZVQZedvRFtmvCh4r80YAvfoiPzl03mnkLgJQxB+3c2Mu+0nyEu79YC+RT+/jMU W2SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=F+wCHIzCyfEvs4AM6zK3GKbsAFgsIIPQRu0jrjTdhgs=; fh=Ccui6pGFIk179IxI3Y+0n789zmEMlmGb9+26aKd2Ylo=; b=zR9md19/ONJI9fWWphrr52/jYqvEeb3kJC6g73wfQb2I+C9/p/ZBPl5JKGd05Ozjl5 vEVuV0JAfKWk37z9Ub4JW+dutgjXkzBzwk9p0Bu+TV4WwWTCqu011Lx9YGfZ7djs4GtN 9A3DyKjzV7hn2Cbk+f05mzxpMiaUT4ZZ0kh7MIJwPugqjW3eis7OtVaBYWOXYMllgSZt Q5smdsWeKfLHx4X901SC3dZaTMNHVaBqH/NgLzw/q1YjnUNbwQ319sLn3C32wog4Jbc2 nMh1EItS+95CQfwXdQ8rykTReeBITP/5cguzCueM4eccpGJNYBI+4YGVc7rcUjy2pZNu ljhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ionos.com header.s=google header.b="G/g/RpYR"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=ionos.com Received: from morse.vger.email (morse.vger.email. [23.128.96.31]) by mx.google.com with ESMTPS id k14-20020a056a00134e00b0068fa57d2442si10139144pfu.130.2023.09.19.08.54.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Sep 2023 08:54:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31; Authentication-Results: mx.google.com; dkim=pass header.i=@ionos.com header.s=google header.b="G/g/RpYR"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=ionos.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id D776B8032106; Tue, 19 Sep 2023 01:19:22 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230395AbjISITD (ORCPT <rfc822;toshivichauhan@gmail.com> + 26 others); Tue, 19 Sep 2023 04:19:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38910 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230439AbjISIS4 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 19 Sep 2023 04:18:56 -0400 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACE68122 for <linux-kernel@vger.kernel.org>; Tue, 19 Sep 2023 01:18:49 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-3ff1c397405so58199165e9.3 for <linux-kernel@vger.kernel.org>; Tue, 19 Sep 2023 01:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ionos.com; s=google; t=1695111528; x=1695716328; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=F+wCHIzCyfEvs4AM6zK3GKbsAFgsIIPQRu0jrjTdhgs=; b=G/g/RpYRSbRVxX2yo5b7MFQEa5GckhzUjYC64KNyOaRyJ1gkEVFapJ+aylrT1W55ys jIHmOXbeGF0bFSI1rxQI3CPGbUsNTbQRcc0JpokO99q7i3dtIIhCIELTRP+sp+gUSPId B3dL+JEqicQ6Mmr9UX5Ij7eu8I9d+/iYwPrn63A2AtlyIVLAsUIfI+SHLGp/Hy8hklI6 s94WmIbY+W8EOxBmTZuwrQyOy1wjkoCyAgeDSMO58/RZUU3QvQmDMJFbyDgWaGuDLgWK YYwhK/AJk8DAmbuWEB/H+3u+Y2aA1eQmHN9mEdxad81+e1FJxbYDT1aDcbG89FuWfv0O IQZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695111528; x=1695716328; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=F+wCHIzCyfEvs4AM6zK3GKbsAFgsIIPQRu0jrjTdhgs=; b=di9o0hRl55SHPVhsGl4Vn3ndKH54Irf3Jbsh3SUGLjdsV4duskZIHPrZ9ejM7ZMjL9 aearyvxQ99a2bMvHyHJiM/FpyLRbifIHlA+qSofeh9pa0GxCIgX4S66gZGY9Nmcxodfb yvxinI6rKYKjtJ7VlGSFL2CE6KKuHyGYuibyUzgeUFNTsQKzMezeSJWCzexgIOOtKCL9 UGZah1sFCrN1wvWKVzDsIy8kzcWEakzoV51fP9sGGvzicCP0ErV6gouEqR4YI1Big9IJ QmROL1c9bcqA9tWxPr0JXQvt4SWVarMuAkCi2+XrZMjVqHH8MKi8c2bkdaOrsLT/Opw/ 1ynw== X-Gm-Message-State: AOJu0YwLb8TW8W4dM5BDhkB1ZQGuaawfikx4NvGI4fYbo1IApJZMS7Ji FSmeb7Pz9sv4wcD8f8mpbRc4HQ== X-Received: by 2002:a05:600c:152:b0:401:bcb4:f119 with SMTP id w18-20020a05600c015200b00401bcb4f119mr11605148wmm.3.1695111527914; Tue, 19 Sep 2023 01:18:47 -0700 (PDT) Received: from heron.intern.cm-ag (p200300dc6f209c00529a4cfffe3dd983.dip0.t-ipconnect.de. [2003:dc:6f20:9c00:529a:4cff:fe3d:d983]) by smtp.gmail.com with ESMTPSA id p14-20020a1c740e000000b003fe407ca05bsm17424445wmc.37.2023.09.19.01.18.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Sep 2023 01:18:47 -0700 (PDT) From: Max Kellermann <max.kellermann@ionos.com> To: Trond Myklebust <trond.myklebust@hammerspace.com>, Anna Schumaker <anna@kernel.org> Cc: Max Kellermann <max.kellermann@ionos.com>, "J . Bruce Fields" <bfields@redhat.com>, stable@vger.kernel.org, linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] nfs/super: check NFS_CAP_ACLS instead of the NFS version Date: Tue, 19 Sep 2023 10:18:44 +0200 Message-Id: <20230919081844.1096767-1-max.kellermann@ionos.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Tue, 19 Sep 2023 01:19:22 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777481956665010961 X-GMAIL-MSGID: 1777481956665010961 |
Series |
nfs/super: check NFS_CAP_ACLS instead of the NFS version
|
|
Commit Message
Max Kellermann
Sept. 19, 2023, 8:18 a.m. UTC
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(-)
Comments
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.org/ ...but it seems like the right thing to do if POSIX ACLs are compiled out. Reviewed-by: Jeff Layton <jlayton@kernel.org>
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;