change log fix: [Patch] bug # 514 (cygwin console handling)

Sorry, I missed to insert the function name in the change log 
entry, so here it is again as an update; the patch is the same.

This is a small patch that fixes
 http://sourceware.org/bugzilla/show_bug.cgi?id=514

Please integrate it into the cygwin DLL.

2004-11-26  Thomas Wolff  <towo <at> computer.org>

* fhandler_console.cc (get_win32_attr): Avoid inappropriate intensity 
     interchanging that used to render reverse output unreadable 
     when (non-reversed) text is bright.
     See http://sourceware.org/bugzilla/show_bug.cgi?id=514
     There are two useful alternatives to handle this; both are in 
     the patch (#ifdef reverse_bright) and one is selected by #define:
     a) (selected) bright foreground will reverse to a bright background,
     b) bright foreground will reverse to a dim background but 
        the background will no longer reverse to a bright foreground 
        (which used to render reverse output unreadable).

--- cygwin-1.5.12-1/winsup/cygwin/fhandler_console.cc	2004-10-28 17:33:04.000000000 +0200
+++ cygwin-1.5.12-1/winsup/cygwin/fhandler_console.cc.fix514	2004-11-30 12:44:03.499523500 +0100
 <at>  <at>  -921,14 +921,32  <at>  <at>  fhandler_console::get_win32_attr ()
   if (dev_state->reverse)
     {
       WORD save_fg = win_fg;
+#define reverse_bright

Re: [Patch] Loading the registry hive on Win9x (part 2)

At 10:25 AM 11/22/2004 -0500, Christopher Faylor wrote:
>
>Other than that, the change looks fine.

Done

Pierre

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

At 11:29 PM 11/25/2004 -0500, Christopher Faylor wrote:
>On Sat, Nov 20, 2004 at 01:23:39AM -0500, Christopher Faylor wrote:
>>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.
>
>I've checked in my revamp of the exec/wait code.  There are still some
>other ways to do what I did and maybe I'll experiment with using
>multiple threads running WaitForMultipleObjects, but, for now, cygwin is
>using the one thread per process technique.

I have downloaded and run a recent snapshot on WinME,
CYGWIN_ME-4.90 hpn5170 1.5.13s(0.116/4/2) 20041125 23:34:52 i686 unknown unknown Cygwin
and tried a few things. I have also gone through the diff.
Here are my initial comments:

- Non cygwin processes started by cygwin are not shown by ps
  anymore and cannot be killed.

- spawn(P_DETACH) does not work correctly when spawning non-cygwin 
  processes.
  This is due to using a pipe to detect process termination. 

- >AFAIK, the only problem with the current code is if a parent process
>forks a process, calls setuid, and execs a non-cygwin process it is
>possible that the parent process won't be able to retrieve the exit
>value of the non-cygwin process.

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

On Thu, Dec 02, 2004 at 09:13:11PM -0500, Pierre A. Humblet wrote:
>- Non cygwin processes started by cygwin are not shown by ps
>  anymore and cannot be killed.
>
>- spawn(P_DETACH) does not work correctly when spawning non-cygwin 
>  processes.
>  This is due to using a pipe to detect process termination. 

The above are both unintentional and fixable.

cgf

Re: [Patch] Fixing the PROCESS_DUP_HANDLE security hole.

[and now the more detailed reply]
On Thu, Dec 02, 2004 at 09:13:11PM -0500, Pierre A. Humblet wrote:
>At 11:29 PM 11/25/2004 -0500, Christopher Faylor wrote:
>I have downloaded and run a recent snapshot on WinME,
>CYGWIN_ME-4.90 hpn5170 1.5.13s(0.116/4/2) 20041125 23:34:52 i686 unknown unknown Cygwin
>and tried a few things. I have also gone through the diff.
>Here are my initial comments:
>
>- Non cygwin processes started by cygwin are not shown by ps
>  anymore and cannot be killed.
>
>- spawn(P_DETACH) does not work correctly when spawning non-cygwin 
>  processes.
>  This is due to using a pipe to detect process termination. 
>
>- >AFAIK, the only problem with the current code is if a parent process
>>forks a process, calls setuid, and execs a non-cygwin process it is
>>possible that the parent process won't be able to retrieve the exit
>>value of the non-cygwin process.
>  I assume you are referring to the use of OpenProcess to reparent, 
>  instead of duplicating the child process handle.

Yes, although cygwin was already using OpenProcess for other things so if
the OpenProcess method was unsafe in this case it would have been unsafe
in the other case, too.

I've eliminated the need for both OpenProcess's but there are still more
sprinkled throughout cygwin.

>This patch uses very innovative methods, but IMHO the net result

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

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

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

[Patch] fhandler.cc: debug_printf when copied_chars is zero.

Hi,

While going over a strace I noticed some garbage in the (debug) output
when fhandler_base::read had read zero bytes. Following (trivial)
patch fixes that.

ChangeLog-entry:

2004-12-05  Bas van Gompel  <cygwin-patch.buzz <at> bavag.tmfweb.nl>

	* fhandler.cc (fhandler_base::read): Don't debug_printf garbage when
	copied_chars is zero.

--- src/winsup/cygwin/fhandler.cc	20 Nov 2004 23:42:36 -0000	1.207
+++ src/winsup/cygwin/fhandler.cc	4 Dec 2004 22:04:38 -0000
 <at>  <at>  -758,6 +758,7  <at>  <at>  fhandler_base::read (void *in_ptr, size_
 	  __small_sprintf (p, c >= 33 && c <= 127 ? " %c" : " %p", c);
 	  p += strlen (p);
 	}
+      *p = '\0';
       debug_printf ("read %d bytes (%s%s)", copied_chars, buf,
 		    copied_chars > 16 ? " ..." : "");
     }

L8r,

Buzz.

BTW: In how-vfork-works.txt, lines 31 and 32 end in CRLF.
BTW2: ansi.sgml has no linefeed at the end of the file.

Re: [Patch] fhandler.cc: debug_printf when copied_chars is zero.

On Sun, Dec 05, 2004 at 12:01:02AM +0100, Bas van Gompel wrote:
>2004-12-05  Bas van Gompel  <cygwin-patch.buzz <at> bavag.tmfweb.nl>
>
>	* fhandler.cc (fhandler_base::read): Don't debug_printf garbage when
>	copied_chars is zero.

Please checkin.

Thanks.

cgf