Prev: Is there anyway to get list of table name, before raw parser is analyze?
Next: pgsql: In walsender, don't sleep if there's outstanding WAL waiting to
From: Peter Eisentraut on 30 May 2010 07:00
It has been discussed several times in the past that there is no way for
a client to authenticate a server over Unix-domain sockets. So
depending on circumstances, a local user could easily insert his own
server and collect passwords and data. Suggestions for possible
remedies included:

You can put the socket file in a sufficiently write-protected directory.
But that would strongly deviate from the default setup, and anyway the
client still cannot readily verify that the server is the right one.

You can also run SSL over Unix-domain sockets. This is currently
disabled in the code, but it would work just fine. But it's obviously
kind of awkward, and the connection overhead was noticeable in tests.

Then it was suggested to use the local "ident" mechanism in reverse, so
the client could verify what user the server runs under. I have
implemented a prototype of this. You can put, e.g.,

requirepeer=postgres

into the connection parameters, and the connection will be rejected
unless the process at the other end of the socket is running as
postgres.

The patch needs some portability work and possible refactoring because
of that, but before I embark on that, comments on the concept?

 | 
Pages: 1
Prev: Is there anyway to get list of table name, before raw parser is analyze?
Next: pgsql: In walsender, don't sleep if there's outstanding WAL waiting to