Re: [musl] Potentially infinite loop in posix_spawn'ed child

[Alexey Izbyshev <izbyshev@ispras.ru>]

On 2021-05-24 18:40, Szabolcs Nagy wrote:
> * 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).
> 
Thanks, I wasn't aware of musl's usage of --dynamic-list and thought 
that weak aliases to hidden symbols (like "weak_alias(__pthread_exit, 
pthread_exit)") are there to prevent interposition.

>> 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.
> 
I never intended this test case to be "supportable usage". This is just 
a hack to make the problem with infinite loop reliably reproducible.

Alexey