Received: by 2002:a05:7412:d8a:b0:e2:908c:2ebd with SMTP id b10csp898296rdg; Wed, 11 Oct 2023 08:27:52 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHgtUG1fODDZaXobp+CG5IEq3DNG9yArDDICnPKI23hXojcLfAN12GXfXGGB5wt5T9Tavqx X-Received: by 2002:a05:6a20:72a2:b0:15e:bf2b:e6d3 with SMTP id o34-20020a056a2072a200b0015ebf2be6d3mr23883163pzk.46.1697038072130; Wed, 11 Oct 2023 08:27:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697038072; cv=none; d=google.com; s=arc-20160816; b=rPbkJ3FxbszhqmRJtAqkbWKxD2ijtkNkYYdArVJwy9m42bcAwriSi/djgpquxnoizD ncBcY317lMlMgOs7dlA/Fv/gtSLIxhHoMN1fUckmo+PlLrkknb2stnTXjbUx5y4E5CNZ dUvdff/GYBzOJzmpoxlMLPzJbe1L6jRTL8Jzhdmb17T9QAzphHbuu6RzYA8Ji0JZM/gN wpE73W5pyMfS3Nu9liAPn27bZ2nDEZ5/z5JCka29grZVxD4TZHOjCPVmFBTSeAhq0cJr sW7NMUibccfGNJp8N5eKSv5NqwnjlLq6qQuqnuVwW3bWm7dP+Oyt7O5OuV7XXoVx5PdS y7EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=7JzoeY751I/pMpp2ntyv4pGkrjgM0+JZ/q+wG6P5xPU=; fh=lV17I06gMNkSH9V8NK56UdYM0qzwkjqmKikdlt9FbUw=; b=N8DpobCyN41Fi2CljJUnmObyy2d9PnOlZ7OtMn+LIDc/7jMqvQPX50GyLHTtJulbkW r+RRTPVUhalHd1fChmcx4icEPMxVFjHpcm64p/PBwQhfDVD+QPG7KrQXnQ8tErl+0LJX I7SGqtPA6cJz13jTDAm1yrND0rvUj1pXf8aPWGEZ9XRPNxVOr4GQC+kONlf8nGP+pkqH jcqwPLnJA8WC/jSwsjQzdtHn/O1oXKwYz3vlYQFE35/vCexwwLUJeTDEbGhcx6vOMqkq 3jHs9dGL7U2bZIGd1iRZRLDlGK82GSd6MI/6F77rvbNdLC6dyajoNXrx2yf78YSdjYO+ FAWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=TaZpnSME; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from pete.vger.email (pete.vger.email. [23.128.96.36]) by mx.google.com with ESMTPS id le7-20020a170902fb0700b001c724cd1128si5390445plb.276.2023.10.11.08.27.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Oct 2023 08:27:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=TaZpnSME; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 1535C807CEC4; Wed, 11 Oct 2023 08:27:46 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232817AbjJKP1p (ORCPT + 99 others); Wed, 11 Oct 2023 11:27:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232760AbjJKP1o (ORCPT ); Wed, 11 Oct 2023 11:27:44 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D2E592; Wed, 11 Oct 2023 08:27:43 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4DB8CC433C7; Wed, 11 Oct 2023 15:27:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697038063; bh=7RZyiacWyfzPvWEqzLgY4Ad7VtrgFG6HkGvT4m3kmO8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TaZpnSMEaI0DGU84iKsQFVVPvyC16VvEM8T5n460Au6MNQ/ww2lxz4UfQ+DA6vXFm BCtrP7/qifoV3YuL88v5Z4hcMkOI/aOIq9hyegqYo11WsSBfpE1ueICf/cUBdDE9Bh A+N2mupq/0QsAcz+XUx3VosdLofH9isxy1pRIIJNYMcYdcT28SYP9Ba8kkcZeNF5g0 ZNuBaGoPPHI6az5feLlT4O9rib8qxW48pAN9rCw9yaJHhnk2reRwFnoBTVt0Bu3F2a V3k//nJlWORSya2SLRtvjvZ6ykCCdUchhQINAPcQQTeolGD+jWvQIO2+kVnB8rQERq hqKdJxh8IxFnA== Date: Wed, 11 Oct 2023 17:27:37 +0200 From: Christian Brauner To: Jan Kara , Max Kellermann Cc: Xiubo Li , Ilya Dryomov , Jeff Layton , Jan Kara , Dave Kleikamp , ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, jfs-discussion@lists.sourceforge.net, Yang Xu , linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v2] fs/{posix_acl,ext2,jfs,ceph}: apply umask if ACL support is disabled Message-ID: <20231011-braumeister-anrufen-62127dc64de0@brauner> References: <69dda7be-d7c8-401f-89f3-7a5ca5550e2f@oracle.com> <20231009144340.418904-1-max.kellermann@ionos.com> <20231010131125.3uyfkqbcetfcqsve@quack3> <20231011100541.sfn3prgtmp7hk2oj@quack3> <20231011120655.ndb7bfasptjym3wl@quack3> <20231011135922.4bij3ittlg4ujkd7@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20231011135922.4bij3ittlg4ujkd7@quack3> X-Spam-Status: No, score=2.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Wed, 11 Oct 2023 08:27:46 -0700 (PDT) X-Spam-Level: ** On Wed, Oct 11, 2023 at 03:59:22PM +0200, Jan Kara wrote: > On Wed 11-10-23 14:27:49, Max Kellermann wrote: > > On Wed, Oct 11, 2023 at 2:18 PM Max Kellermann wrote: > > > But without the other filesystems. I'll resend it with just the > > > posix_acl.h hunk. > > > > Thinking again, I don't think this is the proper solution. This may > > server as a workaround so those broken filesystems don't suffer from > > this bug, but it's not proper. > > > > posix_acl_create() is only supposed to appy the umask if the inode > > supports ACLs; if not, the VFS is supposed to do it. But if the > > filesystem pretends to have ACL support but the kernel does not, it's > > really a filesystem bug. Hacking the umask code into > > posix_acl_create() for that inconsistent case doesn't sound right. > > > > A better workaround would be this patch: > > https://patchwork.kernel.org/project/linux-nfs/patch/151603744662.29035.4910161264124875658.stgit@rabbit.intern.cm-ag/ > > I submitted it more than 5 years ago, it got one positive review, but > > was never merged. > > > > This patch enables the VFS's umask code even if the filesystem > > prerents to support ACLs. This still doesn't fix the filesystem bug, > > but makes VFS's behavior consistent. > > OK, that solution works for me as well. I agree it seems a tad bit cleaner. > Christian, which one would you prefer? So it always bugged me that POSIX ACLs push umask stripping down into the individual filesystems but it's hard to get rid of this. And we tried to improve the situation during the POSIX ACL rework by introducing vfs_prepare_umask(). Aside from that, the problem had been that filesystems like nfs v4 intentionally raised SB_POSIXACL to prevent umask stripping in the VFS. IOW, for them SB_POSIXACL was equivalent to "don't apply any umask". And afaict nfs v4 has it's own thing going on how and where umasks are applied. However, since we now have the following commit in vfs.misc: commit f61b9bb3f8386a5e59b49bf1310f5b34f47bcef9 Author: Jeff Layton AuthorDate: Mon Sep 11 20:25:50 2023 -0400 Commit: Christian Brauner CommitDate: Thu Sep 21 15:37:47 2023 +0200 fs: add a new SB_I_NOUMASK flag SB_POSIXACL must be set when a filesystem supports POSIX ACLs, but NFSv4 also sets this flag to prevent the VFS from applying the umask on newly-created files. NFSv4 doesn't support POSIX ACLs however, which causes confusion when other subsystems try to test for them. Add a new SB_I_NOUMASK flag that allows filesystems to opt-in to umask stripping without advertising support for POSIX ACLs. Set the new flag on NFSv4 instead of SB_POSIXACL. Also, move mode_strip_umask to namei.h and convert init_mknod and init_mkdir to use it. Signed-off-by: Jeff Layton Message-Id: <20230911-acl-fix-v3-1-b25315333f6c@kernel.org> Signed-off-by: Christian Brauner I think it's possible to pick up the first patch linked above: fix umask on NFS with CONFIG_FS_POSIX_ACL=n doesn't lead to any and see whether we see any regressions from this. The second patch I can't easily judge that should go through nfs if at all. So proposal/question: should we take the first patch into vfs.misc?