Re: [autoconf] AmigaOS fork()

[Eric Siegerman]

On Mon, Jun 11, 2001 at 05:31:41PM -0700, Paul Eggert wrote:
>   [...] the Unix tradition is
>   that code that uses 'vfork' can be safely changed to use 'fork' if
>   you like.

If this is a tradition, it's a bad one.  Recall that with vfork,
the child's memory writes, up till it calls some variant of
exec(), ARE visible to the parent.  Code that depends on this
behaviour cannot simply have vfork() calls replaced with fork().
(Not that such code was portably written, of course.  At least
some vfork(2) pages warn against depending on these
memory-sharing semantics.)

In addition, 
http://www.linuxdoc.org/HOWTO/Secure-Programs-HOWTO/avoid-vfork.html
has this to say:
> From a portability point-of-view, the problem with vfork(2) is
> that it's actually fairly tricky for a process to not interfere
> with its parent, especially in high-level languages.  The ``not
> interfering'' requirement applies to the actual machine code
> generated, and many compilers generate hidden temporaries and
> other code structures that cause unintended interference. The
> result: programs using vfork(2) can easily fail when the code
> changes or even when compiler versions change.

The same page also mentions another problem, though perhaps a
less important one since it only applies to some systems: a
kernel bug, with security implications, in versions of Linux ("at
least 2.2 versions through 2.2.17") which are probably still in
production on many machines.

Paul again:
>     #if !HAVE_WORKING_VFORK
>     # define vfork fork
>     #endif
> 
> and then use "vfork" uniformly in the later code.

For the above reasons, I think it would be a bad idea to use
vfork() instead of fork() when both are available, and especially
bad for autoconf to recommend that to people.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)