Re: [PATCH] [BZ #18433] Check file access/existence before forking.

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

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