Skip site navigation (1) Skip section navigation (2)

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

From: "Steve Tibbett" <stibbett(at)zim(dot)biz>
To: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>,"pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCHES] fork/exec patch
Date: 2003-12-16 15:59:58
Message-ID: 546CD3100F4C0F42A30A94C0F2B349148FC612@zimmail1.zim.zimismobile.com (view raw or flat)
Thread:
Lists: pgsql-hackers-win32
>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.

Well, it doesn't matter if it's private or not - if I can find your
HWND,
I can send you a message even if it's a private (nonstandard) message.

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

Well, no - it's a privilege escalation thing.  If I run a terminal
server
with postgresql running with higher privileges than a guest, the guest
can still post messages to your window.. 

Although if the postmaster was running as a service not connected to a
window station (a desktop), then I don't think the guest would be able
to send a message to it's window - but neither would the admin tools :)

Here's another option - what about using a named pipe?  If you want to
send the process a signal, you open the named pipe, write a single byte
to it (the signal value) and close the pipe.

The server process would launch a thread on startup which would create
the server side of the pipe and then do an infinite wait on the pipe
handle.
When the wait returns, it would reads a byte and takes that signal
action -
if the read failed, then it means the main thread has closed the pipe
handle
because it's shutting down, so it would set an event and thread would 
terminate.  

(I don't know if you would do it by launching a thread or if you have
some
other way of waiting on a handle that fits better with how the db agents
are implemented now..)

--
Steve Tibbett
stibbett(at)zim(dot)biz


pgsql-hackers-win32 by date

Next:From: Merlin MoncureDate: 2003-12-16 16:30:06
Subject: Re: [HACKERS] [PATCHES] fork/exec patch
Previous:From: Magnus HaganderDate: 2003-12-16 15:53:07
Subject: Re: [HACKERS] [PATCHES] fork/exec patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group