Received: by 2002:a05:6358:c692:b0:131:369:b2a3 with SMTP id fe18csp148265rwb; Thu, 27 Jul 2023 10:33:47 -0700 (PDT) X-Google-Smtp-Source: APBJJlGGidnEEVEBTqGa23t1XKDF0vMklSweGbo1XGV5/KZFud0gkMP07nS1q8Bx62Rkdm5JxCIz X-Received: by 2002:a17:90b:1e04:b0:268:b57:1695 with SMTP id pg4-20020a17090b1e0400b002680b571695mr3992941pjb.18.1690479227415; Thu, 27 Jul 2023 10:33:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690479227; cv=none; d=google.com; s=arc-20160816; b=bBm3u/EKhH2DSv+Bf1XhXNtEHcHtAa2Y4IpKsxRdNfBAv0GKgtfIU1jDzDtaFF9gZq wD/nMg6ftYCwfornGNF6YRX89Erq7y7d7ySW2yGY+Jggv3WCP2CZzMCEKHs8Ybgu91he Supi9KChnkcMW2H4hiw82+KQ6mzf/gYYmceH9w8bQbob4n7ezX8wb1b8xcb70HcuPG5v d6FFnvOo0xnYN3FFWqN2P3shr7iVO2gQ6YZc98ZyrCnbnRC9Ai/tdVEQ/kxr1iaJ46ps YBSPJkDye4/Okwd3mS8Pxdc+fjZ4TcclhTEfiYiubiXqjzgtSwh1xClh3F9p1YcLWr96 NlEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=roeQEQb5aHv6n9vBFFLl7SB7RwOdrLdMQ0e57Fo99mo=; fh=vyDO39SzkucBUwzXAI50mmJrZs+yq/Bfu7Bl6ovP8Xg=; b=EkqLTIhuftLJIO2A1frB5IjXgCTqWf40+4bmmwtrpn3KJRljeDlvI3fHkKO6+K1MJO xfybESelPSTXXuDm1TuLgq46lVG0jHyapaVGFg4sVOwJyxagzS7P6LN7ByDw+PHsnUCM TOo7LTAlnXKG5TS3KdtHX57aKiDVr58ZjOs/23gYtmcXsXsfn0xiWLxjU3ylfP8dXCbT oNM/cPkRJVoh/xYplLjwotp5BIXkL7x/lqjdCkfWucn28rZueiFv3OvEaab0e2k6GNfj 5KFaywE11LW/EH4RCt1U6pMNR674qVb7AUudHf6zXTwH+GXb8xH6ah082CIIiba9Z/rC lr9w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x8-20020a17090a0bc800b00262fe4585f3si1587374pjd.150.2023.07.27.10.33.35; Thu, 27 Jul 2023 10:33:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232458AbjG0ROF (ORCPT + 99 others); Thu, 27 Jul 2023 13:14:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45874 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232893AbjG0RNr (ORCPT ); Thu, 27 Jul 2023 13:13:47 -0400 Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 806AB3A99 for ; Thu, 27 Jul 2023 10:13:37 -0700 (PDT) Date: Thu, 27 Jul 2023 13:13:37 -0400 From: "dalias@libc.org" To: Christian Brauner Cc: Andreas Schwab , David Laight , 'Aleksa Sarai' , Alexey Gladkov , LKML , Arnd Bergmann , "linux-api@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "viro@zeniv.linux.org.uk" , "James.Bottomley@hansenpartnership.com" , "acme@kernel.org" , "alexander.shishkin@linux.intel.com" , "axboe@kernel.dk" , "benh@kernel.crashing.org" , "borntraeger@de.ibm.com" , "bp@alien8.de" , "catalin.marinas@arm.com" , "christian@brauner.io" , "davem@davemloft.net" , "deepa.kernel@gmail.com" , "deller@gmx.de" , "dhowells@redhat.com" , "fenghua.yu@intel.com" , "fweimer@redhat.com" , "geert@linux-m68k.org" , "glebfm@altlinux.org" , "gor@linux.ibm.com" , "hare@suse.com" , "hpa@zytor.com" , "ink@jurassic.park.msu.ru" , "jhogan@kernel.org" , "kim.phillips@arm.com" , "ldv@altlinux.org" , "linux-alpha@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-ia64@vger.kernel.org" , "linux-m68k@lists.linux-m68k.org" , "linux-mips@vger.kernel.org" , "linux-parisc@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux@armlinux.org.uk" , "linuxppc-dev@lists.ozlabs.org" , "luto@kernel.org" , "mattst88@gmail.com" , "mingo@redhat.com" , "monstr@monstr.eu" , "mpe@ellerman.id.au" , "namhyung@kernel.org" , "paulus@samba.org" , "peterz@infradead.org" , "ralf@linux-mips.org" , "sparclinux@vger.kernel.org" , "stefan@agner.ch" , "tglx@linutronix.de" , "tony.luck@intel.com" , "tycho@tycho.ws" , "will@kernel.org" , "x86@kernel.org" , "ysato@users.sourceforge.jp" , Palmer Dabbelt Subject: Re: [PATCH v4 2/5] fs: Add fchmodat2() Message-ID: <20230727171336.GC20050@brightrain.aerifal.cx> References: <87ila5jp2y.fsf@igel.home> <20230727-zerrt-leitmotiv-9e8b60abf690@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230727-zerrt-leitmotiv-9e8b60abf690@brauner> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 27, 2023 at 07:02:53PM +0200, Christian Brauner wrote: > On Thu, Jul 27, 2023 at 06:28:53PM +0200, Andreas Schwab wrote: > > On Jul 27 2023, David Laight wrote: > > > > > From: Aleksa Sarai > > >> Sent: 25 July 2023 17:36 > > > ... > > >> We almost certainly want to support AT_EMPTY_PATH at the same time. > > >> Otherwise userspace will still need to go through /proc when trying to > > >> chmod a file handle they have. > > > > > > That can't be allowed. > > > > IIUC, fchmodat2(fd, "", m, AT_EMPTY_PATH) is equivalent to fchmod(fd, > > m). With that, new architectures only need to implement the fchmodat2 > > syscall to cover all chmod variants. > > There's a difference though as fchmod() doesn't work with O_PATH file > descriptors while AT_EMPTY_PATH does. Similar to how fchown() doesn't > work with O_PATH file descriptors. > > However, we do allow AT_EMPTY_PATH with fchownat() so there's no reason > to not allow it for fchmodat2(). > > But it's a bit of a shame that O_PATH looks less and less like O_PATH. > It came from can-do-barely-anything to can-do-quite-a-lot-of-things over > the years. > > In any case, AT_EMPTY_PATH for fchmodat2() can be an additional patch on > top. From a standpoint of implementing O_SEARCH/O_EXEC using it, I don't see any reason fchown/fchmod should not work on O_PATH file descriptors. And indeed when you have procfs available to emulate them via procfs, it already does. So I don't see this as unwanted functionality or an access control regression. I see it as things behaving as expected. Semantically, O_PATH is a reference to the inode, not to the dirent. So there is no reason you should not be able to do things that need permission to the inode (changing permissions on it) rather than to the dirent (renaming/moving). Rich