Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp2153700rdd; Fri, 12 Jan 2024 00:27:43 -0800 (PST) X-Google-Smtp-Source: AGHT+IEe2qqRt7bIwvBLv8tT9lP4QIJaMFy+4wijvWGGAiVyEcODCQSHHXFT378ZLVOqeRnYWC54 X-Received: by 2002:a17:907:75fc:b0:a2c:d85c:2c30 with SMTP id jz28-20020a17090775fc00b00a2cd85c2c30mr128890ejc.6.1705048063651; Fri, 12 Jan 2024 00:27:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705048063; cv=none; d=google.com; s=arc-20160816; b=EcYLi0vkwLjAIcgtNX1bVRyQwuMh1+PPZ32AXeD5g2agi4S+OxFXmp7wqJVlm2NpcZ W7yI8mBp8BKvqz44eEnMGYQstFNkHdBPAbdzrcWpvBrI+ElQ4ScAbZRcwANyeC6mMql9 huNHB+B4b45H047IEwYf2CFGx0oLx9hlmpI3tu0l1lMH90g6SrHdxCqrrF4hHqLJ0Y3o gx6LfWri6ACHnLnRBwzN5s7viMxPqGK9BdAhapfy5LbAtZUptnTLa6xsP5IWLST62ECc wgbbWy5wqPl7PkqY0yW9XVTAx4S7k15kKY7tTvzl+J7VaEOMG/Xi9Fb8UCU0p//LVVNf +L0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=l8wqbYuPxm3z1vFd1zakNTbzAQzdJIlD2Y2ZURfm5SM=; fh=tX5EGv6jK/Dl/05Aa90IVl+6fxuZIkQ4Z7yDCdFv4iw=; b=Jxi+ibVqQsZ7kEpYuJB8tmESlTlWT6OxMGeXwIVT6jfm5RmKyxp5rsyL5eZ0n+AKdQ TKCerde+2ES15nYTUB3ZVC6Q6Z/wAuzFkR7T5d9Qz/BAiqGDpUCx4QteHA64TmgyvqeY ycP/ZlhA114w9KzUUdiceeU8lTunD4LGkxQhZYt1jOOgL2X264vnmAVwwFFnUeNZ3Au7 atlEpJfm7bJU22Jt5K7KOMvx49/3OtMq65s3zKop/CZDhpS2xd0RO/BRUABGCR8aUMaP aSzDnsZh+djJsxqr36UxRlpI/FAe4Ap1m3Ndj8XaqgFoELC6tlO9CQl7kmxIw7VeCJJ4 sPlA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hG7OWKPK; spf=pass (google.com: domain of linux-kernel+bounces-24422-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-24422-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id ay20-20020a170906d29400b00a2706ea4afdsi1183253ejb.787.2024.01.12.00.27.43 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jan 2024 00:27:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-24422-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hG7OWKPK; spf=pass (google.com: domain of linux-kernel+bounces-24422-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-24422-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 3ED711F260A7 for ; Fri, 12 Jan 2024 08:27:43 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 17DE65D8F3; Fri, 12 Jan 2024 08:27:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hG7OWKPK" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 391755D753; Fri, 12 Jan 2024 08:27:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC3DAC433C7; Fri, 12 Jan 2024 08:27:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1705048050; bh=/NdXb/L49bbVn5XF5vVNs/DqjuCei7Q3bgf+e+k7RGA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hG7OWKPKJUKRd18+d7vZGF90KYXn73aypHOTjoT5Mpk6KFUDZ1tYxBFAIczGW7EGM mfjrNmT4C4x4d2jPQP5vjR5ymIFR3MH7H2GUZVlvSl6i6Pl7ilUSkKwiXyfDqaOZ5b eRZBOPxvBcIvcdQr5bzKGlf1+eJFlkZQTBGgyZupVuRNHwuOG3/sWWpcI6vyHGWU1P 8pHGBo5jMkU+OqwJODXtCGjx7z8ZAC1LU7o9VKRg2IfIt7weYUYPBoVCzR/WEvx2QV GAsnW8FRWQ8EJ7bf9RIsxfqV3ifB0x5f+AjxXbZqcuEAhdoGFsZGjYCgqBSl77p3K/ xcNp3Kl42Yh6A== Date: Fri, 12 Jan 2024 09:27:24 +0100 From: Christian Brauner To: Steven Rostedt Cc: LKML , Linux Trace Kernel , Masami Hiramatsu , Mathieu Desnoyers , Linus Torvalds , Al Viro , linux-fsdevel@vger.kernel.org, Greg Kroah-Hartman Subject: Re: [PATCH] tracefs/eventfs: Use root and instance inodes as default ownership Message-ID: <20240112-normierung-knipsen-dccb7cac7efc@brauner> References: <20240105-wegstecken-sachkenntnis-6289842d6d01@brauner> <20240105095954.67de63c2@gandalf.local.home> <20240107-getrickst-angeeignet-049cea8cad13@brauner> <20240107132912.71b109d8@rorschach.local.home> <20240108-ortsrand-ziehen-4e9a9a58e708@brauner> <20240108102331.7de98cab@gandalf.local.home> <20240110-murren-extra-cd1241aae470@brauner> <20240110080746.50f7767d@gandalf.local.home> <20240111-unzahl-gefegt-433acb8a841d@brauner> <20240111165319.4bb2af76@gandalf.local.home> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240111165319.4bb2af76@gandalf.local.home> On Thu, Jan 11, 2024 at 04:53:19PM -0500, Steven Rostedt wrote: > On Thu, 11 Jan 2024 22:01:32 +0100 > Christian Brauner wrote: > > > What I'm pointing out in the current logic is that the caller is > > taxed twice: > > > > (1) Once when the VFS has done inode_permission(MAY_EXEC, "xfs") > > (2) And again when you call lookup_one_len() in eventfs_start_creating() > > _because_ the permission check in lookup_one_len() is the exact > > same permission check again that the vfs has done > > inode_permission(MAY_EXEC, "xfs"). > > As I described in: https://lore.kernel.org/all/20240110133154.6e18feb9@gandalf.local.home/ > > The eventfs files below "events" doesn't need the .permissions callback at > all. It's only there because the "events" inode uses it. > > The .permissions call for eventfs has: It doesn't matter whether there's a ->permission handler. If you don't add one explicitly the VFS will simply call generic_permission(): inode_permission() -> do_inode_permission() { if (unlikely(!(inode->i_opflags & IOP_FASTPERM))) { if (likely(inode->i_op->permission)) return inode->i_op->permission(idmap, inode, mask); /* This gets set once for the inode lifetime */ spin_lock(&inode->i_lock); inode->i_opflags |= IOP_FASTPERM; spin_unlock(&inode->i_lock); } return generic_permission(idmap, inode, mask); } > Anyway, the issue is with "events" directory and remounting, because like > the tracefs system, the inode and dentry for "evnets" is created at boot > up, before the mount happens. The VFS layer is going to check the > permissions of its inode and dentry, which will be incorrect if the mount > was mounted with a "gid" option. The gid option has nothing to do with this and it is just handled fine if you remove the second permission checking in (2). You need to remove the inode_permission() code from eventfs_start_creating(). It is just an internal lookup and the fact that you have it in there allows userspace to break readdir on the eventfs portions of tracefs as I've shown in the parts of the mail that you cut off.