Re: [HACKERS] [PATCHES] fork/exec patch
От | Merlin Moncure |
---|---|
Тема | Re: [HACKERS] [PATCHES] fork/exec patch |
Дата | |
Msg-id | 303E00EBDD07B943924382E153890E5434AA27@cuthbert.rcsinc.local обсуждение исходный текст |
Список | pgsql-hackers-win32 |
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); }
В списке pgsql-hackers-win32 по дате отправления: