This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.
At 01:23 AM 11/20/2004 -0500, Christopher Faylor wrote:
>Here's the good news/bad news.
>
>On Tue, Nov 16, 2004 at 10:56:40AM -0500, Christopher Faylor wrote:
>>The simplification of the code from removing all of the reparenting
>>considerations is not something that I'm going to give up on easily.
>
>Well, the code seems to be slightly faster now than the old method,
>so that's something. I think it's also a lot simpler.
>
>There are some ancillary benefits of this new approach. I've fixed the
>old problem where if you run a process from a windows command prompt and
>that process execs another process and it execs another process, each
>process will wait around into the final process in the chain dies.
>
>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?
Pierre