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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proof of concept: standalone backend with full FE/BE protocol
Date: 2012-09-05 10:27:55
Message-ID: CABUevEw7rHYhmfYV8Ve-RzZi0jfWUnEZ6a5BKdu2C1OpVvfVqw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 5, 2012 at 7:31 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
> 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 the main argument. yes. Each client gets it's own copy, so it
can't get drained.

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

Agreed.

Well, what someone else could do is create a pipe with our name before
we do (since we use the actual name - it's \\.\pipe\pgsinal_<pid>), by
guessing what pid we will have. If that happens, we'll go into a loop
and try to recreate it while logging a warning message to
eventlog/stderr. (this happens for every backend). We can't throw an
error on this and kill the backend because the pipe is created in the
background thread not the main one.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gianni Ciolli 2012-09-05 10:42:22 Re: State of the on-disk bitmap index
Previous Message Pavel Stehule 2012-09-05 10:10:17 fixing variadic parameters for type "ANY"