[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241129033419.GI3387508@ZenIV>
Date: Fri, 29 Nov 2024 03:34:19 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Kees Cook <kees@...nel.org>, 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, Nov 28, 2024 at 06:43:31PM -0800, Linus Torvalds wrote:
> 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.
Just one thing - IMO we want to use the relative pathname when it's
not empty. Even in execveat(). Because some wanker *will* decide
that newer is better and make libc use execveat() to implement execve().
Which won't be spotted for about a year, and when it does we'll get
seriously stuck.
I agree that for fexecve() the only sane approach is to go by whatever
that opened file refers to; I'm not sold on the _usefulness_ of
fexecve() to start with, but if we want that thing, that's the way
to go.
Powered by blists - more mailing lists