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.

On Thu, Dec 23, 2004 at 06:23:06PM -0500, Pierre A. Humblet wrote:
>I have run some more tests with a built from cvs this afternoon
>and peeked at some of the changes, so here is some feedback.
>When a process is terminated from Windows, the reported exit code
>is 0. This can easily be fixed by initializing exitcode to
>the value it should take when a process is terminated.

Ok.  I see that the old version of cygwin exited with a status of 1.
I think it is more appropriate to exit with a SIGTERM.

The side effect of doing things this way is that the program will seem
to have exited with a SIGTERM value if it calls ExitProcess, too.
That is a depature from previous behavior that I'm sure I'll hear about.

>If my spawn(P_DETACH) program of yesterday is terminated from 
>Windows during the sleep interval, then the parent process does
>not notice the termination and keeps waiting.

I think I already mentioned this as a side effect of the new code.

>This can be fixed with my lunch time ideas of yesterday.
>Looking at the code, I saw that most of them were already 
>implemented. The only changes are:
>1) remove child_proc_info->parent_wr_proc_pipe stuff
>2) in pinfo::wait, duplicate into non-inheritable wr_proc_pipe

As may not be too surprising, I already considered creating the pipe
before creating the process (somehow I am hearing echoes of John Kerry
here).  I actually coded it that way to begin with but then chose to go
with the current plan.

I'll have to think about my reasons for not implementing it that way.
I don't remember what they are right now.


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