This is the mail archive of the
mailing list for the Cygwin project.
Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.
On Sat, Nov 20, 2004 at 12:54:58PM -0500, Pierre A. Humblet wrote:
>At 01:23 AM 11/20/2004 -0500, Christopher Faylor wrote:
>>On Tue, Nov 16, 2004 at 10:56:40AM -0500, Christopher Faylor wrote:
>>I've also added an 'exitcode' field to _pinfo so that a Cygwin process
>>will set the error code in a UNIX fashion based on whether it is exiting
>>due to a signal or with a normal exit(). Unfortunately, this means that
>>I don't know quite what to do with exit codes from Windows processes.
>>This is the last remaining problem before I check things in. This
>>problem just occurred to me as I was typing in the ChangeLog and it may
>>be the one reason why you actually need to do the reparenting tango.
>For Windows process, why can't you keep doing what was done before
> case WAIT_OBJECT_0:
> sigproc_printf ("subprocess exited");
> DWORD exitcode;
> if (!GetExitCodeProcess (pi.hProcess, &exitcode))
> exitcode = 1;
>and copy the Windows exit code to the exitcode field? Or did you remove the
>subproc_ready as well?
Yes, all of the reparenting logic is gone, including "subproc_ready"; at
least as far as exec is concerned. hProcess doesn't exist in _pinfo
I got the functionality back by essentially implementing reparenting in
a different way, but, now that I've done this, it seems that I don't
need the pipe anymore, even though it does make communication between a
parent and child convenient. So, I still have some cogitating to do.
That's ok. Sleep is overrated.