linux-kernel - Re: [PATCH] vfs: Add AT_EMPTY_PATH_NOCHECK as unchecked AT_EMPTY

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]

Date: Sun, 23 Jun 2024 09:22:12 +0800
From: Xi Ruoyao <xry111@...111.site>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Christian Brauner
	 <brauner@...nel.org>, Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara
	 <jack@...e.cz>, Steven Rostedt <rostedt@...dmis.org>, Masami Hiramatsu
	 <mhiramat@...nel.org>, Alejandro Colomar <alx@...nel.org>, Arnd Bergmann
	 <arnd@...db.de>, Huacai Chen <chenhuacai@...ngson.cn>, Xuerui Wang
	 <kernel@...0n.name>, Jiaxun Yang <jiaxun.yang@...goat.com>, Icenowy Zheng
	 <uwu@...nowy.me>, linux-fsdevel@...r.kernel.org, 
	linux-trace-kernel@...r.kernel.org, linux-arch@...r.kernel.org, 
	loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vfs: Add AT_EMPTY_PATH_NOCHECK as unchecked
 AT_EMPTY_PATH

On Sun, 2024-06-23 at 03:07 +0200, Mateusz Guzik wrote:
> On Sun, Jun 23, 2024 at 2:59 AM Xi Ruoyao <xry111@...111.site> wrote:
> > 
> > On Sat, 2024-06-22 at 15:41 -0700, Linus Torvalds wrote:
> > 
> > > I do think that we should make AT_EMPTY_PATH with a NULL path
> > > "JustWork(tm)", because the stupid "look if the pathname is empty" is
> > > horrible.
> > > 
> > > But moving that check into getname() is *NOT* the right answer,
> > > because by the time you get to getname(), you have already lost.
> > 
> > Oops.  I'll try to get around of getname() too...
> > 
> > > So the short-cut in vfs_fstatat() to never get a pathname is
> > > disgusting - people should have used 'fstat()' - but it's _important_
> > > disgusting.
> > 
> > The problem is we don't have fstat() for LoongArch, and it'll be
> > unusable on all 32-bit arch after 2037.
> > 
> > And Arnd hates the idea adding fstat() for LoongArch because there would
> > be one more 32-bit arch broken in 2037.
> > 
> > Or should we just add something like "fstat_2037()"?
> > 
> 
> In that case fstat is out of the question, but no problem.
> 
> It was suggested to make AT_EMPTY_PATH + NULL pathname do the right
> thing and have the syscalls short-circuit as needed.
> 
> for statx it would look like this (except you are going to have
> implement do_statx_by_fd):
> 
> diff --git a/fs/stat.c b/fs/stat.c
> index 16aa1f5ceec4..0afe72b320cc 100644
> --- a/fs/stat.c
> +++ b/fs/stat.c
> @@ -710,6 +710,9 @@ SYSCALL_DEFINE5(statx,
>         int ret;
>         struct filename *name;
> 
> +       if (flags == AT_EMPTY_PATH && filename == NULL)
> +               return do_statx_by_fd(...);
> +
>         name = getname_flags(filename, getname_statx_lookup_flags(flags));
>         ret = do_statx(dfd, name, flags, mask, buffer);
>         putname(name);
> 
> and so on
> 
> Personally I would prefer if fstatx was added instead, fwiw most
> massaging in the area will be the same regardless.

I do agree.  But if we do it *now* would it be "breaking the userspace"
if some stupid program relies on fstatx() to return some error when the
path is NULL?  The "stupid programs" may just exist in the wild...

I remember recently we have to pretend pidfd is stupid to please some
stupid programs...

https://lore.kernel.org/all/20240521-girlanden-zehnfach-1bff7eb9218c@brauner/

-- 
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University