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

[Florian Weimer <fweimer at redhat dot com>]

On 09/10/2015 11:50 PM, Zack Weinberg wrote:
> On Thu, Sep 10, 2015 at 5:38 PM, navid Rahimi <rahimi.nv@gmail.com> wrote:
>> On Thu, Sep 10, 2015 at 7:32 PM, Zack Weinberg <zackw@panix.com> wrote:
>>> Why is a TOCTOU race acceptable and/or unavoidable? Also, why is a check using the real rather than the effective credentials correct here?
>>
>> Because of nature of lock in unix (being advisory) I think there is no
>> way to lock file and prevent TOCTOU, even if we had lock mechanism ,
>> it is cumbersome (and almost impossible) to design in correctly.
> 
> It just occurred to me that you could open() the file in the parent
> and then use fexecve() in the child.  If that worked correctly it
> would address both my concerns and Phil's.  However, fexecve is faked
> on top of /proc, which means there are all sorts of ways it might not
> work 100% reliably, and for correctness you would need an open mode
> that may not actually exist (O_EXEC, I guess it would be called).

The correct way is to set up a pipe with O_CLOEXEC file descriptors in
the parent prior to forking.  The parent reads from the pipe after
forking, waiting.  When the execve succeeds, the read in the parent
completes without returning any data.  On execve failure, the child
writes the errno value over the pipe, where the parent can read it and
report it.

The downside is that this adds additional blocking to the posix_spawn
operation, which is not something all callers want (some may even prefer
that the vfork happens on a new thread).  So I think this needs a
configuration knob.

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

-- 
Florian Weimer / Red Hat Product Security