Message-ID: <CAHk-=wgKgi5eqo6oW0bBS2-Cr+d4jraoKfVq6wbmdiWWsZbMLw@mail.gmail.com>
Date: Thu, 28 Nov 2024 18:43:31 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kees Cook <kees@...nel.org>
Cc: Al Viro <viro@...iv.linux.org.uk>, linux-kernel@...r.kernel.org, 
	Christophe JAILLET <christophe.jaillet@...adoo.fr>, "Eric W. Biederman" <ebiederm@...ssion.com>, 
	Nir Lichtman <nir@...htman.org>, Tycho Andersen <tandersen@...flix.com>, 
	Vegard Nossum <vegard.nossum@...cle.com>
Subject: Re: [GIT PULL] execve updates for v6.13-rc1 (take 2)

On Thu, 28 Nov 2024 at 18:08, Kees Cook <kees@...nel.org> wrote:
>
> Okay, so, that last thing I can see here as an option is to add an exec-specific AT flag, and if that isn't workable I don't see a way to make this happen with execveat.

So Kees, ask yourself WHY you want to do this idiotic thing in the first place.

You say "isn't workable" and "I don't see a way to make this happen
with execveat".

But be HONEST now. Really - take a step back, and ask yourself what
are actually sane semantics.

And do NOT think about the insane semantics that you have been
spoon-fed by some insane and broken argument where somebody told you
what they wanted and said "this is what systemd needs". A project that
is *famous* for doing things wrong?

Instead, ask yourself that the *sane* semantics are, when you DON'T
come from them from "somebody crazy told me what they want".

Look at regular "execve()". Really. What is "comm[]" when you do an execveat?

It's THE NAME OF THE EXECUTABLE.

It's not "some different thing that was passed in separately".

It wasn't argv[0] for regular execve(), was it? Even though regular
execve() very much also has an argv[0].

So if it wasn't argv[0] for regular execve(), what *is* it, really?

And what is the equivalent for execveat(fd, "", AT_EMPTY_PATH)?

Can you ask yourself that WITHOUT the spoon-fed answer - hint, it was
wrong - that you have been arguing for.

Here's a hint: it's the name of the executable you are running.

That's it. Really.

It clearly was NEVER "argv[0]". That has nothing to do with the name
of the executable, has nothing to do with what regular execve() does,
and clearly has no relationship with what you are executing.

IO tried to tell you. Then I tried to *show* you how even in the
kernel sources we had very real examples of "execveat()" that had a
argv[0] that was entirely unrelated to the executable. You seem to not
have figured it out.

Here's another hint: it's not "", and it's not "some other string I
pass in with a separate flag to give that string meaning".

It's also not the name of the symlink that was dereferenced in an
earlier system call and that resulted in that 'fd' file descriptor.

That symlink is gone. It might literally not exist any more by the
time you do the execveat(), but even if it did, the very act of
opening it made it irrelevant. The open followed the symlink, the
symlink is done with. That's how symlinks work, and it's literally the
difference between a symlink and a hardlink.

And I claim that if you are actually honest about it, you'll come up
with the name that I told you about originally. Because that
dentry->d_name really *IS* the name of the file that is associated
with the 'fd'.

So here's the deal: stop making excuses. Stop ignoring reality. Stop
this idiocy of trying to impose some new meaning on 'comm[]' that
makes no sense, and has *NOTHING* to do with a regular 'execve()'.

And furthermore, start looking at your own motivations. Why are you
taking at face value the word of somebody who claims that "this is
what systemd wants, and the symlink name is magical"?

Face the fact that maybe systemd is famous for bad decisions, and this
is just another example of it.

A sane setup has lots of options

 - just use execve() with the actual name of the executable

 - use hardlinks and use execveat()

 - use open() on a symlink and then execveat() of that file, and get
the actual name of the executable behind the symlink

 - disagree about comm[] being relevant at all, and don't use it, and
don't use tools that do

and none of those are wrong decisions.

But what *is* wrong is to argue for something insane because you
didn't accept the sane end result.

Spend your time trying to convince the systemd people to do the sane
thing instead of trying to make the kernel do something stupid, ok?

Because I'm done with this argument.

If I get more stupid emails on this, I will just block you. Because my
time isn't worth arguing with flat-earthers. Learn to accept reality.
In the kernel we have some taste.

                 Linus

Powered by blists - more mailing lists