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: (view raw, whole thread or download thread mbox)
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

Well, it doesn't matter if it's private or not - if I can find your
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
>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
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
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
because it's shutting down, so it would set an event and thread would 

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

Steve Tibbett

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-2017 The PostgreSQL Global Development Group