Re: Proof of concept: standalone backend with full FE/BE protocol
От | Amit Kapila |
---|---|
Тема | Re: Proof of concept: standalone backend with full FE/BE protocol |
Дата | |
Msg-id | 007901cd8b27$b0808310$11818930$@kapila@huawei.com обсуждение исходный текст |
Ответ на | Re: Proof of concept: standalone backend with full FE/BE protocol (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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 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.
В списке pgsql-hackers по дате отправления: