"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes: > On Sat, 22 Dec 2007 09:25:05 -0500 (EST) > Bruce Momjian <[EMAIL PROTECTED]> wrote: >> I think at a minimum we need to add documentation that states if you >> don't trust the local users on the postmaster server you should: >> >> o create unix domain socket files in a non-world-writable >> directory >> o require SSL server certificates for TCP connections >> >> Ideas? > > It's generally a bad idea to put your database on a public server > anyway but if you do you should definitely disable unix domain sockets > and connect over TCP to localhost. That has been our rule for years. > > It's certainly a corner case. I would think that warnings, perhaps in > the config file itself, would be sufficient.
That seems like a terrible idea. At least while you're dealing with unix domain sockets you know there's no way a remote user could possibly interfere with or sniff your data. As soon as you're dealing with TCP it's a whole new ballgame. X famously had a problem on many OSes where you could spoof the first packet (and if you could predict sequence numbers more than that) of a connection allegedly coming from 127.0.0.1. (it helped that a message to open up connections from anywhere fit in one packet...) Modern OSes include network filters to block such spoofs but it's one more thing you're counting on. Also brought into place are things like forged RST packets, routing table attacks, and on and on. And on the performance front you're dealing with smaller mss and much higher protocol overhead. You also lose bulletproof authentication from unix credentials and are instead relying on properly configuring your network authentication. And it's much easier to accidentally be relying on insecure identd. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster