[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230727-boxte-wohnviertel-74b8541d27ec@brauner>
Date: Thu, 27 Jul 2023 19:36:21 +0200
From: Christian Brauner <brauner@...nel.org>
To: "dalias@...c.org" <dalias@...c.org>
Cc: Andreas Schwab <schwab@...ux-m68k.org>,
David Laight <David.Laight@...LAB.COM>,
'Aleksa Sarai' <cyphar@...har.com>,
Alexey Gladkov <legion@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
"James.Bottomley@...senpartnership.com"
<James.Bottomley@...senpartnership.com>,
"acme@...nel.org" <acme@...nel.org>,
"alexander.shishkin@...ux.intel.com"
<alexander.shishkin@...ux.intel.com>,
"axboe@...nel.dk" <axboe@...nel.dk>,
"benh@...nel.crashing.org" <benh@...nel.crashing.org>,
"borntraeger@...ibm.com" <borntraeger@...ibm.com>,
"bp@...en8.de" <bp@...en8.de>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"christian@...uner.io" <christian@...uner.io>,
"davem@...emloft.net" <davem@...emloft.net>,
"deepa.kernel@...il.com" <deepa.kernel@...il.com>,
"deller@....de" <deller@....de>,
"dhowells@...hat.com" <dhowells@...hat.com>,
"fenghua.yu@...el.com" <fenghua.yu@...el.com>,
"fweimer@...hat.com" <fweimer@...hat.com>,
"geert@...ux-m68k.org" <geert@...ux-m68k.org>,
"glebfm@...linux.org" <glebfm@...linux.org>,
"gor@...ux.ibm.com" <gor@...ux.ibm.com>,
"hare@...e.com" <hare@...e.com>, "hpa@...or.com" <hpa@...or.com>,
"ink@...assic.park.msu.ru" <ink@...assic.park.msu.ru>,
"jhogan@...nel.org" <jhogan@...nel.org>,
"kim.phillips@....com" <kim.phillips@....com>,
"ldv@...linux.org" <ldv@...linux.org>,
"linux-alpha@...r.kernel.org" <linux-alpha@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
"linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
"linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
"linux@...linux.org.uk" <linux@...linux.org.uk>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"luto@...nel.org" <luto@...nel.org>,
"mattst88@...il.com" <mattst88@...il.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"monstr@...str.eu" <monstr@...str.eu>,
"mpe@...erman.id.au" <mpe@...erman.id.au>,
"namhyung@...nel.org" <namhyung@...nel.org>,
"paulus@...ba.org" <paulus@...ba.org>,
"peterz@...radead.org" <peterz@...radead.org>,
"ralf@...ux-mips.org" <ralf@...ux-mips.org>,
"sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
"stefan@...er.ch" <stefan@...er.ch>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"tycho@...ho.ws" <tycho@...ho.ws>,
"will@...nel.org" <will@...nel.org>,
"x86@...nel.org" <x86@...nel.org>,
"ysato@...rs.sourceforge.jp" <ysato@...rs.sourceforge.jp>,
Palmer Dabbelt <palmer@...ive.com>
Subject: Re: [PATCH v4 2/5] fs: Add fchmodat2()
On Thu, Jul 27, 2023 at 01:13:37PM -0400, dalias@...c.org wrote:
> 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
I'm really not talking about the fact that proc is a giant loophole for
basically everyhing related to O_PATH and reopening fds.
I'm saying that both fchmod() and fchown() don't work on O_PATH fds.
They explicitly reject them.
AT_EMPTY_PATH and therefore O_PATH for fchmodat2() is fine given that we
do it for fchownat() already.
Powered by blists - more mailing lists