All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Kees Cook <kees@kernel.org>,
	linux-kernel@vger.kernel.org,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Nir Lichtman <nir@lichtman.org>,
	Tycho Andersen <tandersen@netflix.com>,
	Vegard Nossum <vegard.nossum@oracle.com>
Subject: Re: [GIT PULL] execve updates for v6.13-rc1 (take 2)
Date: Fri, 29 Nov 2024 03:34:19 +0000	[thread overview]
Message-ID: <20241129033419.GI3387508@ZenIV> (raw)
In-Reply-To: <CAHk-=wgKgi5eqo6oW0bBS2-Cr+d4jraoKfVq6wbmdiWWsZbMLw@mail.gmail.com>

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.

  reply	other threads:[~2024-11-29  3:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-21 14:53 [GIT PULL] execve updates for v6.13-rc1 (take 2) Kees Cook
2024-11-25 23:40 ` Linus Torvalds
2024-11-26  5:09   ` Kees Cook
2024-11-26 20:11     ` Linus Torvalds
2024-11-26 20:12       ` Linus Torvalds
2024-11-28  0:53       ` Kees Cook
2024-11-28  1:59         ` Linus Torvalds
2024-11-28  2:05           ` Al Viro
2024-11-28  2:24             ` Linus Torvalds
2024-11-29  2:08               ` Kees Cook
2024-11-29  2:43                 ` Linus Torvalds
2024-11-29  3:34                   ` Al Viro [this message]
2024-11-29  4:23                     ` Eric W. Biederman
2024-11-29  4:48                       ` Al Viro
2024-11-29 17:00                       ` Casey Schaufler
2024-11-29 19:33                       ` Eric W. Biederman
2024-11-29  4:44                     ` Linus Torvalds
2024-11-29 12:41                       ` Eric W. Biederman
2024-11-29 21:42                       ` Vegard Nossum
2024-11-29 22:54                         ` Al Viro
2024-11-30  4:24                         ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241129033419.GI3387508@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=ebiederm@xmission.com \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nir@lichtman.org \
    --cc=tandersen@netflix.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vegard.nossum@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.