Re: Proof of concept: standalone backend with full FE/BE protocol

On Tuesday, September 04, 2012 12:40 AM Tom Lane wrote:
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Mon, Sep 3, 2012 at 8:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I have another question after thinking about that for awhile: is there
>>> any security concern there? On Unix-oid systems, we expect the kernel
>>> to restrict who can do a kill() on a postgres process. If there's any
>>> similar restriction on who can send to that named pipe in the Windows
>>> version, it's not obvious from the code. Do we have/need any
>>> restriction there?

>> We use the default for CreateNamedPipe() which is:
>> " The ACLs in the default security descriptor for a named pipe grant
>> full control to the LocalSystem account, administrators, and the
>> creator owner. They also grant read access to members of the Everyone
>> group and the anonymous account."
>> (ref:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365150(v=vs.85).as
px)

> Hm. The write protections sound fine ... but what's the semantics of
> reading, is it like Unix pipes? If so, couldn't a random third party
> drain the pipe by reading from it, and thereby cause signals to be lost?

When a client connects to the server-end of a named pipe, the server-end
of the pipe is now dedicated to the client. No
more connections will be allowed to that server pipe instance until the
client has disconnected.
This is from paper: http://www.blakewatts.com/namedpipepaper.html, it
mentions about security issues in named pipes.

The function CallNamedPipe() used for sending signal in pgkill() has
following definition:
Connects to a message-type pipe (and waits if an instance of the pipe is
not available), writes to and reads from the
pipe, and then closes the pipe.
(http://msdn.microsoft.com/en-us/library/windows/desktop/aa365144(v=vs.85).a
spx)

So I think based on above 2 points it can be deduced that the signal sent
by pgkill() cannot be read by anyone else.

With Regards,
Amit Kapila.