Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> Yeah, all of this is about confusion and error-proneness. I still think > >> that the real problem is that we don't have full control over > >> client-side code, and therefore can't just write off the problem of a > >> client deciding to connect to /tmp/.s.PGSQL.5432 even if the local DBA > >> thinks the socket would be safer elsewhere. > > > Right. I think the lock file in /tmp does help somewhat. > > Even if it happens to work (on some platforms) it seems like a kluge. > > It strikes me that given the postmaster's infrastructure for listening > on multiple sockets, it would be a pretty small matter of programming > to teach it to listen on socket files in multiple directories not only > one. If we had that, the postmaster could listen in both /tmp and > your-more-secure-directory-of-choice. Surely an actual socket file > would be a more useful "blocker" in /tmp than a dead-weight PID file.
The problem with creating a working second socket in /tmp is that the client would succeed with the insecure socket location and when the server is down spoofing is possible. I figure the client should fail so users know the client is incorrectly/insecurely configured. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
