Re: [HACKERS] [PATCHES] fork/exec patch

Steve Tibbett wrote:
>
> >IMNSHO it might be easier in the long run to work with message
> >handlers instead of events.

> I'd say avoid this if you can.. shared memory and events is cleaner in
> that messages are more for GUI apps than for services.. otherwise
> you're going to have a window handle and a message pump around just
> for this.
>
> Also, there's no security on an HWND, so unless you're going to verify
> the permissions some other way you'd lose the security you have
> available
> to protect you from any process being able to send you signals. This
is
>
> the basis for the Shatter attacks on win32.

OK, you have a point. There is even one more thing that I thought about
in that services are restricted in message handling capabilities in NT
unless you explicitly disable that protection (basically a security fix
for the scatter attack). So messages are probably out, unless this
restriction does not apply to 'child' processes which off the top of my
head I am not sure about. However scatter attack type problems do not
really apply because the postmaster would only listen for private
messages (or public ones and implement the standard behavior). IMO, the
scatter problem was overhyped.

I would also like to point out that executing scatter requires executing
code on a compromised machine, at which point the machine is completely
compromised, so the security issue is also somewhat moot. Win32
unfortunately is inherently insecure from the terminal. Despite that,
detail message handling by service applications are not vulnerable
unless very poorly designed.

Also, in Microsoft's own UNIX conversion guide (a good read!), at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/
html/UCMGch09.asp
They mention both approaches. Security issues aside, I think
implementing a callback is easier than dealing with WaitForSingleObject,
but for Postgres's case, maybe events are superior. Still, there is
some attractiveness for simplicity's sake to have a backend die on
WM_QUIT. Also, messages are slightly cleaner (by avoiding share memory
use) in emulation of sigaction (does postgres use this?).

Also, storing the signal type in shared memory (as in the CONNX code)
seems overkill because the signal ID (along with the pid) can be stored
in the name of the event. Here is Microsoft's example (from the above
link) on emulating SIGALRM with events:

#define _WIN32_WINNT 0X0500

#include <windows.h>
#include <stdio.h>
#include <conio.h>
#include <stdlib.h>

void main()
{
HANDLE hTimer = NULL;
LARGE_INTEGER liDueTime;

liDueTime.QuadPart = -50000000;

printf("alarm application starting\n");

// Set up a 5 second timer object
hTimer = CreateWaitableTimer(NULL, TRUE, "WaitableTimer");
SetWaitableTimer(hTimer, &liDueTime, 0, NULL, NULL, 0);

// Now wait for the alarm
printf("waiting for alarm\n");

// Wait for the timer object
WaitForSingleObject(hTimer, INFINITE);
printf("Ring...Ring!\n");
printf("alarm application done\n");
exit(0);
}