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

[Zack Weinberg <zackw at panix dot com>]

On Wed, Sep 30, 2015 at 7:48 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 09/18/2015 06:52 PM, Zack Weinberg wrote:
>> (I actually have a design sketched out in my head; unfortunately I
>> have neither the time nor the kernel programming experience to get it
>> done.  The fundamental idea is a new process state, "egg," in which
>> the process has a PID and a task_struct assigned but does not have an
>> address space and cannot execute instructions.  There are a bunch of
>> new system calls to set the kernel state of an egg -- open file
>> descriptors and the like -- and a modified execve() that loads a
>> program into an egg and sets it going.)
>
> I think we actually have most bits in the kernel (what you are proposing
> is a lot like the restore part of the checkpoint/restore support), we
> just have to fit things together properly.
>
> One thing that we can't really address: Some callers want to know the
> child PID *before* the execve (so that pthread_spawn does not delay
> execution), some want to know precisely if execve succeeded.  We
> probably need to introduce a flag to choose between the two behaviors
> because they are fundamentally incompatible.

This is a non-issue if applications code to the new kernel API rather
than posix_spawn. egg_create() returns the new PID, which you always
need to know, and egg_execve(pid, ...) tells you if it failed.

(A critical aspect of my idea, which I guess I forgot to mention, is
that all the new setting-up-the-egg syscalls report failure in the
*parent*; this wipes out a whole class of problems with failures in
between fork() and execve() being difficult to report accurately.)

zw