I've never found a recommendation to run Postgresql on a privileged port in production. What type of port should be used in production regarding security and best practices?

  • What operating system? Aug 17, 2018 at 16:44
  • 1
    Linux. Sorry for leaving that out.
    – da99
    Aug 17, 2018 at 16:54
  • 1
    Why would you want to run Postgresql on a privileged port? Why run on any port other then the default? Changing ports is merely security through obscurity anyway. Aug 17, 2018 at 17:00
  • @Colin'tHart If I use a non-privilege port, won't any executable be able to take over the port and listen in on the traffic? Granted, this is general advice I have read and not specific to PG deployments.
    – da99
    Aug 17, 2018 at 17:07
  • 3
    In production, PostgreSQL will typically be on its own box alone without user accounts or on a box where user accounts are considered to be safe, that is not knowingly attacking things by trying to start processes that bind on important ports. Also PostgreSQL should be configured to start on boot before many other things, which reduce the window opportunity to grab its TCP/IP port. Aug 17, 2018 at 18:17

2 Answers 2


Running PostgreSQL under 1024 requires some hacking. It's almost impossible outside of win32. From the backend/main/main.c,

"root" execution of the PostgreSQL server is not permitted. The server must be started under an unprivileged user ID to prevent possible system security compromise. See the documentation for more information on how to properly start the server.

After which the backend calls exit(1). It also doesn't run as a setuid script. From the source,

Also make sure that real and effective uids are the same. Executing as a setuid program from a root shell is a security hole, since on many platforms a nefarious subroutine could setuid back to root if real uid is root. (Since nobody actually uses postgres as a setuid program, trying to actively fix this situation seems more trouble than it's worth; we'll just expend the effort to check for it.)

The only way to even set this up on Linux that I know of is

However, if you are worried about server spoofing (another server taking over the non-privilege connection before the PG executable) you can still be secure if you take some pre-cautions, as explained in Preventing Server Spoofing:

  • Local connection: use a Unix domain socket directory (unix_socket_directories) that has write permission only for a trusted local user.
  • Local connection: use requirepeer to specify the required owner of the server process connected to the socket.
  • TCP connection: the best solution is to use SSL certificates and make sure that clients check the server's certificate.
  • 1
    What about using setcap with CAP_NET_BIND_SERVICE on the executable? Or would that lead to just another security hole?
    – da99
    Aug 17, 2018 at 16:57
  • SSH port-forwarding is the simple and secure way to bind any service to any desired port not already used.
    – Kondybas
    Aug 17, 2018 at 16:58
  • @da99 I actually think that may work I'll update my post. Aug 17, 2018 at 17:02
  • @EvanCarroll Thanks again for all your help.
    – da99
    Aug 17, 2018 at 17:14
  • 1
    erg, turn off connections from Unix domain socket. Not UDP, typo. Aug 17, 2018 at 17:30

Using a privileged port for Postgres would require the postgres daemon to run with root privileges, which in itself is a security vulnerability. So, no, you should not use a privileged port for Postgres.

  • "to run with root privileges" or be just given the appropriate capability to bind to low numbered ports. No need for full root rights to do that on any modern Unix system. See this example: stackoverflow.com/a/414258/6368697 Aug 17, 2018 at 18:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.