From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,URIBL_BLACK
	autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 12070 invoked from network); 24 May 2021 15:40:30 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 24 May 2021 15:40:30 -0000
Received: (qmail 18371 invoked by uid 550); 24 May 2021 15:40:28 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 18350 invoked from network); 24 May 2021 15:40:27 -0000
Date: Mon, 24 May 2021 17:40:14 +0200
From: Szabolcs Nagy <nsz@port70.net>
To: Alexey Izbyshev <izbyshev@ispras.ru>
Cc: musl@lists.openwall.com
Message-ID: <20210524154014.GA790988@port70.net>
Mail-Followup-To: Alexey Izbyshev <izbyshev@ispras.ru>,
	musl@lists.openwall.com
References: <985e15962c164eb3076752d6ee4c05fe@ispras.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <985e15962c164eb3076752d6ee4c05fe@ispras.ru>
Subject: Re: [musl] Potentially infinite loop in posix_spawn'ed child

* Alexey Izbyshev <izbyshev@ispras.ru> [2021-05-24 13:09:21 +0300]:
> As an aside, perhaps it would make sense to call execve() in posix_spawn()
> implementation via a hidden symbol? This would both make it consistent with
> posix_spawnp() and avoid any trouble with user code executing in a vfork'ed
> child if execve() is overridden via e.g. LD_PRELOAD.

libc symbols cannot be interposed by user code, they are
all resolved within the libc, there should be no dynamic
symbolic relocation in libc.so except for global data and
malloc symbols (those are explicitly exported).

so musl posix_spawn always calls musl's execve.
except with static linking you cannot hide libc symbols
like that unless musl uses a different name internally
(but that prevents the compiler recognizing builtins in
libc code if we ever want to optimize them).

> #include <errno.h>
> #include <signal.h>
> #include <spawn.h>
> #include <unistd.h>
> 
> static int p[2];
> 
> int execve(const char *path, char *const argv[], char *const envp[]) {

this is only called with static linking, but that is not
supportable usage: libc may provide execve and e.g. signal
in the same object file and then there is a conflict
because signal has to be linked. so this is just a user
error.

>   close(p[1]);
>   kill(getppid(), SIGKILL);
>   read(p[0], &(char){0}, 1);
>   errno = ENOENT;
>   return -1;
> }
> 
> int main(int argc, char *argv[], char *envp[]) {
>     signal(SIGPIPE, SIG_IGN);
>     pipe(p);
>     posix_spawn(0L, "/non-existing", 0L, 0L, argv, envp);
>     return 0;
> }