[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