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

[Florian Weimer <fweimer at redhat dot com>]

On 09/18/2015 06:52 PM, Zack Weinberg wrote:
> On Wed, Sep 16, 2015 at 4:35 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>> On 15/09/15 23:02, Mike Frysinger wrote:
>>> On 14 Sep 2015 15:04, Szabolcs Nagy wrote:
>>>> On 11/09/15 22:01, Zack Weinberg wrote:
>>>>> On Fri, Sep 11, 2015 at 5:18 AM, Florian Weimer wrote:
>>>>>> 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.
>>>>
>>>> because fork has issues [...]
>>>
>>> how does posix_spawn magically fix these things ?  it still calls
>>> fork internally [...]
>>
>> the api is such that user code is not run with a copy of the
>> address space in the child so an implementation without fork
>> is possible (that's the point of this api). [...]  (of course the kinds
>> of actions before exec are limited by the api so it's not always
>> useful/simple).
> 
> So that means migrating to posix_spawn doesn't fix anything until a
> better kernel API exists, so developer effort should go into _that_,
> and then applications should migrate directly to the new kernel API,
> not to posix_spawn.

posix_spawn is not a kernel API.  If applications move to that, we can
add optimizations as soon as better kernel APIs become available, and
applications will directly benefit.  That's the nice aspect of
pthread_spawn.  The not-so-nice aspect from an application point of view
is that the interface is so restrictive, and glibc basically has to vet
and implement any child process configuration option.

> (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.

-- 
Florian Weimer / Red Hat Product Security