Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +