From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50064C04A94 for ; Fri, 28 Jul 2023 08:44:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234992AbjG1Io0 convert rfc822-to-8bit (ORCPT ); Fri, 28 Jul 2023 04:44:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42410 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234960AbjG1IoH (ORCPT ); Fri, 28 Jul 2023 04:44:07 -0400 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E6DEC3A94 for ; Fri, 28 Jul 2023 01:44:03 -0700 (PDT) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-66-QuWuNYGHMBmrzfdm4fjM8A-1; Fri, 28 Jul 2023 09:44:01 +0100 X-MC-Unique: QuWuNYGHMBmrzfdm4fjM8A-1 Received: from AcuMS.Aculab.com (10.202.163.4) by AcuMS.aculab.com (10.202.163.4) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Fri, 28 Jul 2023 09:43:58 +0100 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Fri, 28 Jul 2023 09:43:58 +0100 From: David Laight To: 'Aleksa Sarai' , Alexey Gladkov CC: 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" , "dalias@libc.org" , "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() Thread-Topic: [PATCH v4 2/5] fs: Add fchmodat2() Thread-Index: AQHZwLFLeKGBJJpK+0qJRy2agWp2qK/O266A Date: Fri, 28 Jul 2023 08:43:58 +0000 Message-ID: References: <20230727.041348-imposing.uptake.velvet.nylon-712tDwzCAbCCoSGx@cyphar.com> <20230727.173441-loving.habit.lame.acrobat-V6VTPe8G4FRI@cyphar.com> In-Reply-To: <20230727.173441-loving.habit.lame.acrobat-V6VTPe8G4FRI@cyphar.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org ... > FWIW, I agree with Christian that these behaviours are not ideal (and > I'm working on a series that might allow for these things to be properly > blocked in the future) but there's also the consistency argument -- I > don't think fchownat() is much safer to allow in this way than > fchmodat() and (again) this behaviour is already possible through > procfs. If the 'through procfs' involves readlink("/proc/self/fd/n") and accessing through the returned path then the permission checks are different. Using the returned path requires search permissions on all the directories. This is all fine for xxxat() functions where a real open directory fd is supplied. But other cases definitely need a lot of thought to ensure they don't let programs acquire permissions they aren't supposed to have. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)