[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <02a4eba412e82db36c06952bc8b81825@ispras.ru>
Date: Mon, 24 May 2021 19:50:57 +0300
From: Alexey Izbyshev <izbyshev@...ras.ru>
To: Szabolcs Nagy <nsz@...t70.net>
Cc: musl@...ts.openwall.com
Subject: Re: Potentially infinite loop in posix_spawn'ed child
On 2021-05-24 18:40, Szabolcs Nagy wrote:
> * Alexey Izbyshev <izbyshev@...ras.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
