Re: SSL over Unix-domain sockets

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. +