On Wednesday, September 05, 2012 3:58 PM Magnus Hagander wrote:
On Wed, Sep 5, 2012 at 7:31 AM, Amit Kapila <amit.kapila@huawei.com> wrote:
> On Tuesday, September 04, 2012 12:40 AM Tom Lane wrote:
> 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).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.
Once it is detected that already a same Named Pipe already exists, there
can be following options:
a. try to create with some other name, but in that case how to communicate
the new name to client end of pipe. Some solution can be thought if this approach seems to be reasonable,
though currently I don't have any in mind. b. give error, as creation of pipe is generally at beginning of process
creation(backend), but you already mentioned it is not good approach. c. any other better solution?
With Regards,
Amit Kapila.
