linux-kernel - Re: [PATCH v4 0/5] Add a new fchmodat2() syscall

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230712024243.GX20050@brightrain.aerifal.cx>
Date:   Tue, 11 Jul 2023 22:42:44 -0400
From:   Rich Felker <dalias@...c.org>
To:     Alexey Gladkov <legion@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>,
        linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        viro@...iv.linux.org.uk, James.Bottomley@...senPartnership.com,
        acme@...nel.org, alexander.shishkin@...ux.intel.com,
        axboe@...nel.dk, benh@...nel.crashing.org, borntraeger@...ibm.com,
        bp@...en8.de, catalin.marinas@....com, christian@...uner.io,
        davem@...emloft.net, deepa.kernel@...il.com, deller@....de,
        dhowells@...hat.com, fenghua.yu@...el.com, fweimer@...hat.com,
        geert@...ux-m68k.org, glebfm@...linux.org, gor@...ux.ibm.com,
        hare@...e.com, hpa@...or.com, ink@...assic.park.msu.ru,
        jhogan@...nel.org, kim.phillips@....com, ldv@...linux.org,
        linux-alpha@...r.kernel.org, linux-arch@...r.kernel.org,
        linux-ia64@...r.kernel.org, linux-m68k@...ts.linux-m68k.org,
        linux-mips@...r.kernel.org, linux-parisc@...r.kernel.org,
        linux-s390@...r.kernel.org, linux-sh@...r.kernel.org,
        linux@...linux.org.uk, linuxppc-dev@...ts.ozlabs.org,
        luto@...nel.org, mattst88@...il.com, mingo@...hat.com,
        monstr@...str.eu, mpe@...erman.id.au, namhyung@...nel.org,
        paulus@...ba.org, peterz@...radead.org, ralf@...ux-mips.org,
        sparclinux@...r.kernel.org, stefan@...er.ch, tglx@...utronix.de,
        tony.luck@...el.com, tycho@...ho.ws, will@...nel.org,
        x86@...nel.org, ysato@...rs.sourceforge.jp
Subject: Re: [PATCH v4 0/5] Add a new fchmodat2() syscall

On Tue, Jul 11, 2023 at 06:16:02PM +0200, Alexey Gladkov wrote:
> In glibc, the fchmodat(3) function has a flags argument according to the
> POSIX specification [1], but kernel syscalls has no such argument.
> Therefore, libc implementations do workarounds using /proc. However,
> this requires procfs to be mounted and accessible.
> 
> This patch set adds fchmodat2(), a new syscall. The syscall allows to
> pass the AT_SYMLINK_NOFOLLOW flag to disable LOOKUP_FOLLOW. In all other
> respects, this syscall is no different from fchmodat().
> 
> [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/chmod.html
> 
> Changes since v3 [cover.1689074739.git.legion@...nel.org]:
> 
> * Rebased to master because a new syscall has appeared in master.
> * Increased __NR_compat_syscalls as pointed out by Arnd Bergmann.
> * Syscall renamed fchmodat4 -> fchmodat2 as suggested by Christian Brauner.
> * Returned do_fchmodat4() the original name. We don't need to version
>   internal functions.
> * Fixed warnings found by checkpatch.pl.
> 
> Changes since v2 [20190717012719.5524-1-palmer@...ive.com]:
> 
> * Rebased to master.
> * The lookup_flags passed to sys_fchmodat4 as suggested by Al Viro.
> * Selftest added.
> 
> Changes since v1 [20190531191204.4044-1-palmer@...ive.com]:
> 
> * All architectures are now supported, which support squashed into a
>   single patch.
> * The do_fchmodat() helper function has been removed, in favor of directly
>   calling do_fchmodat4().
> * The patches are based on 5.2 instead of 5.1.

It's good to see this moving forward. I originally proposed this in a
patch submitted in 2020. I suspect implementation details have changed
since then, but it might make sense to look back at that discussion if
nobody has done so yet (apologies if this was already done and I
missed it) to make sure nothing is overlooked -- I remember there were
some subtleties with what fs backends might try to do with chmod on
symlinks. My proposed commit message also documented a lot of the
history of the issue that might be useful to have as context.

https://lore.kernel.org/all/20200910170256.GK3265@brightrain.aerifal.cx/T/

Rich