a list for submitting patches to the Cygwin DLL and the other components of the "winsup" directory

Pierre A. Humblet | 4 Dec 2004 17:45

Picon

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

At 12:43 AM 12/4/2004 -0500, Christopher Faylor wrote:
>
>I wrote a simple test case to check this and I don't see it -- on XP.  I
>can't easily run Me anymore.  Does the attached program demonstrate this
>behavior when you run it?  It should re-exec itself every time you hit
>CTRL-C.

That test case has no problem, but the attached one does. 
Use kill -30 pid

Pierre

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/signal.h>

void ouch (int sig)
{
  printf ("got signal %d\n", sig);
  return;
}

int
main (int argc, char **argv)
{
  if (getppid() != 1 && fork())
    exit(0);
  signal (SIGUSR1, ouch);

(Continue reading)

Pierre A. Humblet | 4 Dec 2004 19:01

Picon

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

At 12:33 PM 12/4/2004 -0500, Christopher Faylor wrote:
>On Sat, Dec 04, 2004 at 11:45:28AM -0500, Pierre A. Humblet wrote:
>>At 12:43 AM 12/4/2004 -0500, Christopher Faylor wrote:
>>>I wrote a simple test case to check this and I don't see it -- on XP.  I
>>>can't easily run Me anymore.  Does the attached program demonstrate this
>>>behavior when you run it?  It should re-exec itself every time you hit
>>>CTRL-C.
>>
>>That test case has no problem, but the attached one does. 
>>Use kill -30 pid
>
>Sigh.  Works fine on XP, AFAICT.

More details
CYGWIN_ME-4.90 hpn5170 1.5.13s(0.116/4/2) 20041125 23:34:52 i686 unknown
unknown Cygwin

I added a printf at the top, showing the current pid and ppid
(attached)

~: ./a
pid 556021 ppid 890585
~: ps | fgrep /A
  36793321       1  556021 4258173975    0  740 12:47:22 /c/HOME/PIERRE/A
~: kill -30 36793321
got signal 30
execing myself
~: pid 36793321 ppid 36793321
~: ps | fgrep /A
  36765717       1  556021 4258201579    0  740 12:47:44 /c/HOME/PIERRE/A

(Continue reading)

Christopher Faylor | 5 Dec 2004 02:00

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

On Sat, Dec 04, 2004 at 01:01:11PM -0500, Pierre A. Humblet wrote:
>At 12:33 PM 12/4/2004 -0500, Christopher Faylor wrote:
>>On Sat, Dec 04, 2004 at 11:45:28AM -0500, Pierre A. Humblet wrote:
>>>At 12:43 AM 12/4/2004 -0500, Christopher Faylor wrote:
>>>>I wrote a simple test case to check this and I don't see it -- on XP.  I
>>>>can't easily run Me anymore.  Does the attached program demonstrate this
>>>>behavior when you run it?  It should re-exec itself every time you hit
>>>>CTRL-C.
>>>
>>>That test case has no problem, but the attached one does. 
>>>Use kill -30 pid
>>
>>Sigh.  Works fine on XP, AFAICT.
>
>More details
>CYGWIN_ME-4.90 hpn5170 1.5.13s(0.116/4/2) 20041125 23:34:52 i686 unknown
>unknown Cygwin
>
>I added a printf at the top, showing the current pid and ppid
>(attached)
>
>~: ./a
>pid 556021 ppid 890585
>~: ps | fgrep /A
>  36793321       1  556021 4258173975    0  740 12:47:22 /c/HOME/PIERRE/A
>~: kill -30 36793321
>got signal 30
>execing myself
>~: pid 36793321 ppid 36793321
>~: ps | fgrep /A

(Continue reading)

Christopher Faylor | 13 Dec 2004 21:25

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

With the current CVS, I am seeing the same (suboptimal) behavior on
Windows Me that I do in 1.5.12.

If I type a bunch of "sleep 60&" at the command line, then "bash" won't
exit until the last sleep 60 has terminated.  I can't explain why this
is.  It doesn't work that way on XP, of course.

While "bash" is waiting, I see no sign of it in the process table so
it's odd behavior.

The current CVS should work better with exim now, though.

cgf

Pierre A. Humblet | 14 Dec 2004 15:41

Picon

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

Christopher Faylor wrote:
> 
> With the current CVS, I am seeing the same (suboptimal) behavior on
> Windows Me that I do in 1.5.12.
>
> If I type a bunch of "sleep 60&" at the command line, then "bash" won't
> exit until the last sleep 60 has terminated.  I can't explain why this
> is.  It doesn't work that way on XP, of course.
> 
> While "bash" is waiting, I see no sign of it in the process table so
> it's odd behavior.

1.5.12, the current official release? I have never observed it there.
Also my recollection is that the delay was not necessarily equal
to the sleep duration.

> The current CVS should work better with exim now, though.

Are you done with the changes? I will try a snapshot and look at the
code in the coming days. Not much free time currently.

Pierre

Christopher Faylor | 14 Dec 2004 16:42

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

On Tue, Dec 14, 2004 at 09:41:41AM -0500, Pierre A. Humblet wrote:
>Christopher Faylor wrote:
>>With the current CVS, I am seeing the same (suboptimal) behavior on
>>Windows Me that I do in 1.5.12.
>>
>>If I type a bunch of "sleep 60&" at the command line, then "bash" won't
>>exit until the last sleep 60 has terminated.  I can't explain why this
>>is.  It doesn't work that way on XP, of course.
>>
>>While "bash" is waiting, I see no sign of it in the process table so
>>it's odd behavior.
>
>1.5.12, the current official release?  I have never observed it there.
>Also my recollection is that the delay was not necessarily equal to the
>sleep duration.

It's 1.5.12, the official release.  Testing anything else wouldn't really
be useful.

If I type

c:\>bash
bash-2.05b$ sleep 20&
bash-2.05b$ exit

There will be a ~20 second wait before bash exits.

I think I vaguely recall this from when I was mucking up the signal code
a year ago.

(Continue reading)

Pierre A. Humblet | 22 Dec 2004 17:13

Picon

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

I tried my spawn(P_DETACH) example (updated since yesterday)
with the latest snapshot, this time on NT. 

#include <stdio.h>
#include <unistd.h>
#include <process.h>

main()
{
    spawnl(_P_DETACH, "/c/WINNT/system32/notepad", "notepad", 0);
    printf("Spawn done\n");
    /* Keep working */
    sleep(10);
    printf("Exiting\n");
}

New problem is with gcc (gcc version 3.3.3 (cygwin special))
~/try> uname -a
CYGWIN_NT-4.0 usched40576 1.5.12(0.116/4/2) 2004-11-10 08:34 i686 unknown unknown Cygwin
~/try> gcc -o try_spawn try_spawn.c
~/try> 

~/try> uname -a
CYGWIN_NT-4.0 usched40576 1.5.13s(0.117/4/2) 20041221 16:19:37 i686 unknown unknown Cygwin
~/try> gcc -o xxx try_spawn.c
In file included from /usr/include/stdio.h:45,
                 from try_spawn.c:1:
/usr/include/sys/reent.h:810: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

(Continue reading)

Pierre A. Humblet | 22 Dec 2004 19:44

Picon

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

"Pierre A. Humblet" wrote:
>
> When running try_spawn with the snapshot, during the sleep period
> ps reports
> 
>       690     443     690        232    0 11054 10:32:21 <defunct>
>       464     690     690        464    0 11054 10:32:21 /c/WINNT/system32/notepad

FWIW, I was thinking about this during lunch.
The basic issue is that the pipe to the parent is not closed in the spawned
Windows process. One way out is to make the pipe non-inheritable and
duplicate it either in the parent (fork and spawn, except detach)
or in the child (exec). Now that subproc_ready is back, it doesn't matter
that an exec'ed Windows process does not duplicate the pipe.

Pierre

Pierre A. Humblet | 24 Dec 2004 00:23

Picon

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

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.

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.

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
3) make wr_proc_pipe inheritable just before exec
4) make wr_proc_pipe non-inheritable when starting after exec
 (or better? at the first fork or spawn, leaving 2) as currently done)

Comments on pinfo.cc comments:
Delete: "but, unfortunately, reparenting is still needed ..."
        It's really gone, isn't it?
Update: "We could just let this happen automatically when the process.."
        to indicate it's needed by P_DETACH (at least with current code)

Pierre

Pierre A. Humblet | 24 Dec 2004 03:54

Picon

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

At 09:27 PM 12/23/2004 -0500, Christopher Faylor wrote:
>On Thu, Dec 23, 2004 at 06:23:06PM -0500, Pierre A. Humblet wrote:
>
>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.

Good point. But even if you leave it to be 0, the complain will be that
the exit value won't be passed. Of course a Cygwin program should call
exit.

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

I must have missed it.

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

(Continue reading)

Pierre A. Humblet | 24 Dec 2004 05:05

Picon

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

At 10:50 PM 12/23/2004 -0500, Christopher Faylor wrote:
>On Thu, Dec 23, 2004 at 09:54:20PM -0500, Pierre A. Humblet wrote:
>>At 09:27 PM 12/23/2004 -0500, Christopher Faylor wrote:
>>>On Thu, Dec 23, 2004 at 06:23:06PM -0500, Pierre A. Humblet wrote:
>
>FWIW, I modified cygwin so that it seems as if with a status of '1' if
>you use ExitProcess and a status of "SIGTERM" (as in terminated by a
>signal) if you kill a process via task manager (aka TerminateProcess).

Good. 

>>>>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.
>>
>>That's fine, and I am not suggesting that you should change your way.
>
>Ah.  I didn't get that the first two times you explained it.  Now I get
>it.  Sorry.
>
>>Perhaps I wasn't clear. Just duplicate the pipe into the new process,
>>as you do now, but not inheritable. The new process makes it inheritable
>>before execing a new new process.

(Continue reading)

Pierre A. Humblet | 24 Dec 2004 05:59

Picon

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

At 11:35 PM 12/23/2004 -0500, Christopher Faylor wrote:
>On Thu, Dec 23, 2004 at 11:05:50PM -0500, Pierre A. Humblet wrote:
>>At 10:50 PM 12/23/2004 -0500, Christopher Faylor wrote:
>>>On Thu, Dec 23, 2004 at 09:54:20PM -0500, Pierre A. Humblet wrote:
>>>>At 09:27 PM 12/23/2004 -0500, Christopher Faylor wrote:
>>>>>On Thu, Dec 23, 2004 at 06:23:06PM -0500, Pierre A. Humblet wrote:
>>>
>>>FWIW, I modified cygwin so that it seems as if with a status of '1' if
>>>you use ExitProcess and a status of "SIGTERM" (as in terminated by a
>>>signal) if you kill a process via task manager (aka TerminateProcess).
>>
>>Good. 
>>
>>>>>>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.
>>>>
>>>>That's fine, and I am not suggesting that you should change your way.
>>>
>>>Ah.  I didn't get that the first two times you explained it.  Now I get
>>>it.  Sorry.
>>>
>>>>Perhaps I wasn't clear. Just duplicate the pipe into the new process,

(Continue reading)

Pierre A. Humblet | 24 Dec 2004 14:40

Picon

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

At 12:54 AM 12/24/2004 -0500, Pierre A. Humblet wrote:
>At 12:25 AM 12/24/2004 -0500, Christopher Faylor wrote:
>>On Thu, Dec 23, 2004 at 11:59:59PM -0500, Pierre A. Humblet wrote:
>>>At 11:35 PM 12/23/2004 -0500, Christopher Faylor wrote:
>>>>I don't think you need it.  You just need to tell a process which is
>>>>about to exec after having been execed to make sure that its
>>>>wr_proc_pipe is valid.
>>>
>>>Yes, that's the key. So the question is only about method. Either the
parent
>>>guarantees that the child has a valid handle, or the child must check
>>>that it already has a valid handle or wait until it does. 
>>
>>I have just implemented code which causes an execed child to wait for the
>>parent to fill in its wr_proc_pipe if it is going to exec again.  It uses
>>a busy loop but I think it's unlikely that the loop will be exercised too
>>often.
>
>It's late, but I am trying to go through all permutations.
>Here is a strange one. 
>Cygwin process A started from Windows execs a Windows process B.
>We are in the case where A
>      if (!myself->wr_proc_pipe)
>       {
>         myself.remember (true);
>         wait_for_myself = true;
>
>The problem is that later there is
>if (wait_for_myself)
>  waitpid (myself->pid, &res, 0);

(Continue reading)

Christopher Faylor | 24 Dec 2004 16:40

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

On Fri, Dec 24, 2004 at 08:40:29AM -0500, Pierre A. Humblet wrote:
>At 12:54 AM 12/24/2004 -0500, Pierre A. Humblet wrote:
>I think the way out is as follows:
>Toward the end of spawn_guts:
>
>ciresrv.sync (myself, INFINITE);   [always]
>
>if (wait_for_myself)
>   waitpid (myself->pid, &dummy, 0);
> [For clarity, these two lines should be brought down
>  inside the case _P_OVERLAY: ]

Yes, I thought of this last night as I was trying to sleep.  It also
dawned on me that I need to synchronize wr_proc_pipe any time it is
used.  Otherwise an exec followed by a quick SIGSTOP may not work.

I almost got up to make these changes but, instead, I just dreamed
about them all night and had a crappy night's sleep.

The change to pinfo::exit didn't occur to me but it is logical.  I
have made that change.

cgf

Pierre A. Humblet | 24 Dec 2004 06:54

Picon

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

At 12:25 AM 12/24/2004 -0500, Christopher Faylor wrote:
>On Thu, Dec 23, 2004 at 11:59:59PM -0500, Pierre A. Humblet wrote:
>>At 11:35 PM 12/23/2004 -0500, Christopher Faylor wrote:
>>>I don't think you need it.  You just need to tell a process which is
>>>about to exec after having been execed to make sure that its
>>>wr_proc_pipe is valid.
>>
>>Yes, that's the key. So the question is only about method. Either the parent
>>guarantees that the child has a valid handle, or the child must check
>>that it already has a valid handle or wait until it does. 
>
>I have just implemented code which causes an execed child to wait for the
>parent to fill in its wr_proc_pipe if it is going to exec again.  It uses
>a busy loop but I think it's unlikely that the loop will be exercised too
>often.

It's late, but I am trying to go through all permutations.
Here is a strange one. 
Cygwin process A started from Windows execs a Windows process B.
We are in the case where A
      if (!myself->wr_proc_pipe)
       {
         myself.remember (true);
         wait_for_myself = true;

The problem is that later there is
if (wait_for_myself)
  waitpid (myself->pid, &res, 0);
else
  ciresrv.sync (myself, INFINITE);

(Continue reading)

Christopher Faylor | 24 Dec 2004 06:25

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

On Thu, Dec 23, 2004 at 11:59:59PM -0500, Pierre A. Humblet wrote:
>At 11:35 PM 12/23/2004 -0500, Christopher Faylor wrote:
>>I don't think you need it.  You just need to tell a process which is
>>about to exec after having been execed to make sure that its
>>wr_proc_pipe is valid.
>
>Yes, that's the key. So the question is only about method. Either the parent
>guarantees that the child has a valid handle, or the child must check
>that it already has a valid handle or wait until it does. 

I have just implemented code which causes an execed child to wait for the
parent to fill in its wr_proc_pipe if it is going to exec again.  It uses
a busy loop but I think it's unlikely that the loop will be exercised too
often.

I'm testing it now.

cgf

Christopher Faylor | 24 Dec 2004 05:35

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

On Thu, Dec 23, 2004 at 11:05:50PM -0500, Pierre A. Humblet wrote:
>At 10:50 PM 12/23/2004 -0500, Christopher Faylor wrote:
>>On Thu, Dec 23, 2004 at 09:54:20PM -0500, Pierre A. Humblet wrote:
>>>At 09:27 PM 12/23/2004 -0500, Christopher Faylor wrote:
>>>>On Thu, Dec 23, 2004 at 06:23:06PM -0500, Pierre A. Humblet wrote:
>>
>>FWIW, I modified cygwin so that it seems as if with a status of '1' if
>>you use ExitProcess and a status of "SIGTERM" (as in terminated by a
>>signal) if you kill a process via task manager (aka TerminateProcess).
>
>Good. 
>
>>>>>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.
>>>
>>>That's fine, and I am not suggesting that you should change your way.
>>
>>Ah.  I didn't get that the first two times you explained it.  Now I get
>>it.  Sorry.
>>
>>>Perhaps I wasn't clear. Just duplicate the pipe into the new process,
>>>as you do now, but not inheritable. The new process makes it inheritable

(Continue reading)

Christopher Faylor | 24 Dec 2004 04:50

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

On Thu, Dec 23, 2004 at 09:54:20PM -0500, Pierre A. Humblet wrote:
>At 09:27 PM 12/23/2004 -0500, Christopher Faylor wrote:
>>On Thu, Dec 23, 2004 at 06:23:06PM -0500, Pierre A. Humblet wrote:
>>
>>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.
>
>Good point. But even if you leave it to be 0, the complain will be that
>the exit value won't be passed.

Right.

>Of course a Cygwin program should call >exit.

Right.

FWIW, I modified cygwin so that it seems as if with a status of '1' if
you use ExitProcess and a status of "SIGTERM" (as in terminated by a
signal) if you kill a process via task manager (aka TerminateProcess).

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

(Continue reading)

Christopher Faylor | 24 Dec 2004 03:27

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

(Continue reading)

Pierre A. Humblet | 22 Dec 2004 19:54

Picon

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.


"Pierre A. Humblet" wrote:
> 
> "Pierre A. Humblet" wrote:
> >
> > When running try_spawn with the snapshot, during the sleep period
> > ps reports
> >
> >       690     443     690        232    0 11054 10:32:21 <defunct>
> >       464     690     690        464    0 11054 10:32:21 /c/WINNT/system32/notepad
> 
> FWIW, I was thinking about this during lunch.
> The basic issue is that the pipe to the parent is not closed in the spawned
> Windows process. One way out is to make the pipe non-inheritable and
> duplicate it either in the parent (fork and spawn, except detach)
> or in the child (exec). Now that subproc_ready is back, it doesn't matter
> that an exec'ed Windows process does not duplicate the pipe.

Actually, the parent is supposed to disappear anyway in the case of
an exec. So it could make the pipe inheritable just before the exec.
In multithreaded programs, other threads should be forbidden to
fork and spawn once a thread has called exec.

Pierre

Christopher Faylor | 22 Dec 2004 17:22

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

On Wed, Dec 22, 2004 at 11:13:30AM -0500, Pierre A. Humblet wrote:
>I tried my spawn(P_DETACH) example (updated since yesterday)
>with the latest snapshot, this time on NT. 
>
>#include <stdio.h>
>#include <unistd.h>
>#include <process.h>
>
>main()
>{
>    spawnl(_P_DETACH, "/c/WINNT/system32/notepad", "notepad", 0);
>    printf("Spawn done\n");
>    /* Keep working */
>    sleep(10);
>    printf("Exiting\n");
>}
>
>New problem is with gcc (gcc version 3.3.3 (cygwin special))
>~/try> uname -a
>CYGWIN_NT-4.0 usched40576 1.5.12(0.116/4/2) 2004-11-10 08:34 i686 unknown unknown Cygwin
>~/try> gcc -o try_spawn try_spawn.c

This is unrelated to the process changes.  Corinna checked in a patch
for this at 11:31 GMT.

cgf

Christopher Faylor | 4 Dec 2004 18:33

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

On Sat, Dec 04, 2004 at 11:45:28AM -0500, Pierre A. Humblet wrote:
>At 12:43 AM 12/4/2004 -0500, Christopher Faylor wrote:
>>I wrote a simple test case to check this and I don't see it -- on XP.  I
>>can't easily run Me anymore.  Does the attached program demonstrate this
>>behavior when you run it?  It should re-exec itself every time you hit
>>CTRL-C.
>
>That test case has no problem, but the attached one does. 
>Use kill -30 pid

Sigh.  Works fine on XP, AFAICT.

I'll try harder to get WinMe working later today.

cgf

Return

Return to gmane.os.cygwin.patches.

Advertisement

Project Web Page

a list for submitting patches to the Cygwin DLL and the other components of the "winsup" directory

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane