[PATCH] [BZ #18433] Check file access/existence before forking.
Szabolcs Nagy
szabolcs.nagy@arm.com
Mon Sep 14 14:05:00 GMT 2015
On 11/09/15 22:01, Zack Weinberg wrote:
> On Fri, Sep 11, 2015 at 5:18 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>> All in all I am inclined to say leave things as they are. Nobody uses
>>> posix_spawn if they can help it, anyway :)
>>
>> We need to move people off fork and clone to posix_spawn. If it is
>> missing functionality, we should add it.
>
> ... I honestly have no idea why you say that. I am under the
because fork has issues
- spawn process from a large application (memory overcommit off)
is unreliable with fork.
- using it from a multi-threaded application (so from a library)
is hard, because the child has to be AS-safe.
- leaks sensitive information to the child (the sensitive info
is often managed by a library and there is no way of safely
clearing it on fork).
- pthread_atfork is broken, further limiting the applicability
of fork in multi-threaded code (it cannot be implemented if
fork has to be AS-safe and the interface contract of the
callbacks are ill-defined).
- it has no simple implementation if the underlying platform has
no fork syscall with the right semantics (posix on windows,
nommu,...)
> impression that posix_spawn is a monstrosity from the days when the
> POSIX committee was inclined to make up interfaces out of whole cloth
> in order to fix things that weren't broken, and that it should under
> no circumstances be used in new code.
posix_spawn is the only standard interface that can
work (some) fork limitations around.
new code should use it instead of fork (or vfork) if
possible.
>
> zw
>
More information about the Libc-alpha
mailing list