linux-kernel - Re: [GIT PULL] execve updates for v6.13-rc1

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: <CAHk-=whF03ueoCM7M0vbcTy7fRvv+g9h_rnafurNJ1OEj71cEA@mail.gmail.com>
Date: Thu, 21 Nov 2024 13:48:59 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Zbigniew Jędrzejewski-Szmek <zbyszek@...waw.pl>
Cc: Kees Cook <kees@...nel.org>, "Eric W. Biederman" <ebiederm@...ssion.com>, linux-kernel@...r.kernel.org, 
	Alexander Viro <viro@...iv.linux.org.uk>, 
	Christophe JAILLET <christophe.jaillet@...adoo.fr>, Dan Carpenter <dan.carpenter@...aro.org>, 
	Nir Lichtman <nir@...htman.org>, syzbot+03e1af5c332f7e0eb84b@...kaller.appspotmail.com, 
	Tycho Andersen <tandersen@...flix.com>, Vegard Nossum <vegard.nossum@...cle.com>
Subject: Re: [GIT PULL] execve updates for v6.13-rc1

On Thu, 21 Nov 2024 at 13:31, Zbigniew Jędrzejewski-Szmek
<zbyszek@...waw.pl> wrote:
>
> The point is that comm _is_ used in many places that matter. I'm not
> sure what you're trying to say really, since in the second half of
> your mail you actually showed an example where this is true.

Really, let me say this one more time: if you don't like the dentry
name, don't give execveat() a bare file descriptor that has no other
name, and claim that you want to use some completely unrelated third
thing that has nothing to do with it except in your little
dream-world.

The dentry name is not just fine, it's THE TRUTH. It's fundamentally
what you are executing.

It's better than - and fundamentally different from - argv[0], which
is something entirely different and is defined to be available
elsewhere.

If you have done an open() that followed a symlink, the name *behind*
the symlink is the *CORRECT* name. So when you then do an execveat(),
it's literally the thing *behind* the symlink that you are executing.

You are trying to claim that people want argv[0]. No they don't. If
they wanted argv[0], they'd use /proc/*/cmdline, which already give
you that, and more.

And if they don't want argv[0], then they get the name that the
executable was started with. Which is the name *behind* the symlink
that was resolved by the (preceding) 'open()'.

I'm trying to explain to you that comm[] IS NOT, AND HAS NEVER BEEN,
argv[0]. The two have *never* matched up and been the same thing. It's
simply not how execve() works.

I understand that you seem to *think* that it is how execve() works or
should work, but that's your hangup, and has no actual basis in
reality.

I'm telling you that comm[] is not argv[0], and has never been argv[0]. Ever.

I will not take that idiotic patch that tries to change decades of
history, based on what is purely your personal misunderstanding of
what argv[0] is, and does something *stupid* and slow, when something
much more true is right there in the dentry name.

I don't even understand why you care about the symlink thing. You did
an open, you followed the symlink, the file no longer points to the
symlink, trying to claim that it does is simply not *true* in any
shape or form.

Here's a hint for you: do the same open, but never execute it. Then
look in /proc/*/fd and see what that says. Horror of horrors, it
doesn't show the symlink. It shows what it pointed to.

And before you start arguing about that too, let me just say that
we're not changing that *either*.

           Linus