Re: [PATCH v4 2/5] fs: Add fchmodat2()
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: David Laight <David.Laight@xxxxxxxxxx>
- Subject: Re: [PATCH v4 2/5] fs: Add fchmodat2()
- From: "dalias@xxxxxxxx" <dalias@xxxxxxxx>
- Date: Fri, 28 Jul 2023 14:42:12 -0400
- Cc: "'Aleksa Sarai'" <cyphar@xxxxxxxxxx>, Alexey Gladkov <legion@xxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>, "linux-api@xxxxxxxxxxxxxxx" <linux-api@xxxxxxxxxxxxxxx>, "linux-fsdevel@xxxxxxxxxxxxxxx" <linux-fsdevel@xxxxxxxxxxxxxxx>, "viro@xxxxxxxxxxxxxxxxxx" <viro@xxxxxxxxxxxxxxxxxx>, "James.Bottomley@xxxxxxxxxxxxxxxxxxxxx" <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>, "acme@xxxxxxxxxx" <acme@xxxxxxxxxx>, "alexander.shishkin@xxxxxxxxxxxxxxx" <alexander.shishkin@xxxxxxxxxxxxxxx>, "axboe@xxxxxxxxx" <axboe@xxxxxxxxx>, "benh@xxxxxxxxxxxxxxxxxxx" <benh@xxxxxxxxxxxxxxxxxxx>, "borntraeger@xxxxxxxxxx" <borntraeger@xxxxxxxxxx>, "bp@xxxxxxxxx" <bp@xxxxxxxxx>, "catalin.marinas@xxxxxxx" <catalin.marinas@xxxxxxx>, "christian@xxxxxxxxxx" <christian@xxxxxxxxxx>, "davem@xxxxxxxxxxxxx" <davem@xxxxxxxxxxxxx>, "deepa.kernel@xxxxxxxxx" <deepa.kernel@xxxxxxxxx>, "deller@xxxxxx" <deller@xxxxxx>, "dhowells@xxxxxxxxxx" <dhowells@xxxxxxxxxx>, "fenghua.yu@xxxxxxxxx" <fenghua.yu@xxxxxxxxx>, "fweimer@xxxxxxxxxx" <fweimer@xxxxxxxxxx>, "geert@xxxxxxxxxxxxxx" <geert@xxxxxxxxxxxxxx>, "glebfm@xxxxxxxxxxxx" <glebfm@xxxxxxxxxxxx>, "gor@xxxxxxxxxxxxx" <gor@xxxxxxxxxxxxx>, "hare@xxxxxxxx" <hare@xxxxxxxx>, "hpa@xxxxxxxxx" <hpa@xxxxxxxxx>, "ink@xxxxxxxxxxxxxxxxxxxx" <ink@xxxxxxxxxxxxxxxxxxxx>, "jhogan@xxxxxxxxxx" <jhogan@xxxxxxxxxx>, "kim.phillips@xxxxxxx" <kim.phillips@xxxxxxx>, "ldv@xxxxxxxxxxxx" <ldv@xxxxxxxxxxxx>, "linux-alpha@xxxxxxxxxxxxxxx" <linux-alpha@xxxxxxxxxxxxxxx>, "linux-arch@xxxxxxxxxxxxxxx" <linux-arch@xxxxxxxxxxxxxxx>, "linux-ia64@xxxxxxxxxxxxxxx" <linux-ia64@xxxxxxxxxxxxxxx>, "linux-m68k@xxxxxxxxxxxxxxxxxxxx" <linux-m68k@xxxxxxxxxxxxxxx>, "linux-mips@xxxxxxxxxxxxxxx" <linux-mips@xxxxxxxxxxxxxxx>, "linux-parisc@xxxxxxxxxxxxxxx" <linux-parisc@xxxxxxxxxxxxxxx>, "linux-s390@xxxxxxxxxxxxxxx" <linux-s390@xxxxxxxxxxxxxxx>, "linux-sh@xxxxxxxxxxxxxxx" <linux-sh@xxxxxxxxxxxxxxx>, "linux@xxxxxxxxxxxxxxx" <linux@xxxxxxxxxxxxxxx>, "linuxppc-dev@xxxxxxxxxxxxxxxx" <linuxppc-dev@xxxxxxxxxxxxxxxx>, "luto@xxxxxxxxxx" <luto@xxxxxxxxxx>, "mattst88@xxxxxxxxx" <mattst88@xxxxxxxxx>, "mingo@xxxxxxxxxx" <mingo@xxxxxxxxxx>, "monstr@xxxxxxxxx" <monstr@xxxxxxxxx>, "mpe@xxxxxxxxxxxxxx" <mpe@xxxxxxxxxxxxxx>, "namhyung@xxxxxxxxxx" <namhyung@xxxxxxxxxx>, "paulus@xxxxxxxxx" <paulus@xxxxxxxxx>, "peterz@xxxxxxxxxxxxx" <peterz@xxxxxxxxxxxxx>, "ralf@xxxxxxxxxxxxxx" <ralf@xxxxxxxxxxxxxx>, "sparclinux@xxxxxxxxxxxxxxx" <sparclinux@xxxxxxxxxxxxxxx>, "stefan@xxxxxxxx" <stefan@xxxxxxxx>, "tglx@xxxxxxxxxxxxx" <tglx@xxxxxxxxxxxxx>, "tony.luck@xxxxxxxxx" <tony.luck@xxxxxxxxx>, "tycho@xxxxxxxx" <tycho@xxxxxxxx>, "will@xxxxxxxxxx" <will@xxxxxxxxxx>, "x86@xxxxxxxxxx" <x86@xxxxxxxxxx>, "ysato@xxxxxxxxxxxxxxxxxxxx" <ysato@xxxxxxxxxxxxx>, Palmer Dabbelt <palmer@xxxxxxxxxx>
- In-reply-to: <dc48b40748e24d3799e7ee66fa7e8cb4@AcuMS.aculab.com>
- References: <cover.1689074739.git.legion@kernel.org> <cover.1689092120.git.legion@kernel.org> <f2a846ef495943c5d101011eebcf01179d0c7b61.1689092120.git.legion@kernel.org> <njnhwhgmsk64e6vf3ur7fifmxlipmzez3r5g7ejozsrkbwvq7w@tu7w3ieystcq> <ZMEjlDNJkFpYERr1@example.org> <20230727.041348-imposing.uptake.velvet.nylon-712tDwzCAbCCoSGx@cyphar.com> <20230727.173441-loving.habit.lame.acrobat-V6VTPe8G4FRI@cyphar.com> <dc48b40748e24d3799e7ee66fa7e8cb4@AcuMS.aculab.com>
- User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Jul 28, 2023 at 08:43:58AM +0000, David Laight wrote:
> ....
> > 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.
That's *not* how "through procfs" works. The "magic symlinks" in
/proc/*/fd are not actual symlinks that get dereferenced to the
contents they readlink() to, but special-type objects that dereference
directly to the underlying file associated with the open file
description.
Rich
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]