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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Magnus Hagander <magnus@hagander.net>
Cc: Amit Kapila <amit.kapila@huawei.com>, pgsql-hackers@postgresql.org
Date: 2012-09-03T19:10:22Z
Lists: pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> On Mon, Sep 3, 2012 at 8:51 PM, Tom Lane <tgl@sss.pgh.pa.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).aspx)

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?

			regards, tom lane


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove now redundant pgpipe code.