Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

[Christopher Faylor <cgf-no-personal-reply-please at cygwin dot com>]

On Sun, Nov 14, 2004 at 12:34:30PM -0500, Pierre A. Humblet wrote:
>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?

AFAIK, you can't do async I/O on anonymous pipes.

>BTW, have you ever tried using select, having a connection from the
>parent to the child?

select involves polling or setting up other events to track end-of-pipe
conditions.  I don't think that's a win.

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

It could but that's not its intent.  It's used now to transmit stop/continue
state but if you need to send a signal from parent to child, I don't think
it makes sense to relay it through this mechanism.

cgf