While the server is running, it is not possible for a malicious
user to take the place of the normal database server. However, when
the server is down, it is possible for a local user to spoof the
normal server by starting their own server. The spoof server could
read passwords and queries sent by clients, but could not return
any data because the
would still be secure because of directory permissions. Spoofing is
possible because any user can start a database server; a client
cannot identify an invalid server unless it is specially
One way to prevent spoofing of
local connections is to use a Unix domain socket
that has write permission only for a trusted local user. This
prevents a malicious user from creating their own socket file in
that directory. If you are concerned that some applications might
/tmp for the socket
file and hence be vulnerable to spoofing, during operating system
startup create a symbolic link
/tmp/.s.PGSQL.5432 that points to the relocated
socket file. You also might need to modify your
/tmp cleanup script to prevent removal of the
Another option for
connections is for clients to use
requirepeer to specify the required owner of
the server process connected to the socket.
To prevent spoofing on TCP connections, the best solution is to
use SSL certificates and make sure that clients check the server's
certificate. To do that, the server must be configured to accept
hostssl connections (Section 20.1) and have
SSL key and certificate files (Section 18.9).
The TCP client must connect using
verify-full and have the appropriate root
certificate file installed (Section 33.18.1).
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.