This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

At 01:03 PM 11/14/2004 -0500, Christopher Faylor wrote:
>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:
>>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.

I meant the Windows select, on sockets.

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

Then something else is needed. An advantage of the relay is that it could
allow only stop/continue to pass through. The ppid_waitsig lets all signals
go through.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]