Messages in this thread |  | | From | Linus Torvalds <> | | Date | Thu, 28 Nov 2024 18:43:31 -0800 | | Subject | Re: [GIT PULL] execve updates for v6.13-rc1 (take 2) |
| |
On Thu, 28 Nov 2024 at 18:08, Kees Cook <kees@kernel.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
|  |