Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

["Pierre A. Humblet" <pierre at phumblet dot no-ip dot org>]

At 12:11 AM 11/14/2004 -0500, Christopher Faylor wrote:
>
>When you first mentioned this, I had an idea that maybe we could be
>waiting on something else besides a process handle which would be
>inherited by any subprocesses.  I thought that maybe we could somehow
>use a mutex but there would always be a period when you'd have to do
>some tricky synchronization to make sure that the child gets to lock the
>mutex but the parent doesn't.
>
>I don't know how many times I have wished for a non-process handle that
>would become signalled when a process exits.
>
>So, today, it occurred to me that pipes could come to the rescue again.
>If we opened a pipe and put the write end in every child process, the
>parent could wait on the read end of the pipe.  When the last child
>process dies, the parent would wake up and do what it does now.
>
>At first, I was hoping that pipes would work correctly when called
>with WaitFor* and we could just drop pipe handles in there.  Of course,
>it can't be that simple and I really should have known that wouldn't
>work.  I think I have tried this technique about twice a year since
>1998.
>
>Instead, you have to use ReadFile in a thread.  So, the children would
>gain an extra open handle, the parent would get some new threads.  But
>the parent would be able to track A LOT more subprocesses than the
>current 63.

That would be the key advantage of this approach. Do you have a
way (async I/O?) to avoid having one thread per child?
BTW, have you ever tried using select, having a connection from the
parent to the child?
 
>I just implemented most of this and it seems to work ok.  One side
>effect of this technique is that any subprocess created with
>CreateProcess will also inherit the pipe and so, a parent cygwin process
>will wait for all of the processes created with CreateProcess.  I'm not
>sure if I really care about that, though.
>
>The other negative side effect is the overhead of creating a pipe and a
>thread.  I don't think this is noticeable and this technique eliminates
>some overhead in cygwin, too.  It's not exactly a wash, but I'm hoping
>it won't be too bad, regardless.
>
>When I get the code to a point that it can run configure, I'll do a
>benchmark and see how bad this technique is.  If there is not a
>noticeable degradation, I think I'll probably duplicate the scenario of
>last year and checkin this revamp which, I believe will eliminate the
>security problem that you were talking about.

There is also the case where a setuid child needs to signal its parent.
That's another use of my ppid_waitsig, avoiding the PROCESS_DUP_HANDLE
issue.
Could your "end of pid" pipe be used to transmit signals, with the reader
thread forwarding the sigpacket to the local sigthread?

Pierre