Re: SSL over Unix-domain sockets

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Yea, I figured using protected directories for the socket was the
> zero-cost solution, and if you have to do SSL, might as well just use
> TCP too. (If you moved the socket file to a protected directory I think
> you could use external_pid_file='/tmp/.s.PGSQL.5432' to prevent a spoof
> socket file in /tmp. Should we document that idea?)

Umm ... two questions about that:

* will the postmaster fail if there's a socket where it tries to write
the external_pid_file? (If it does fail, does that really fix
anything? The spoofer already owns the socket.)

* if there's a plain file where a client expects to find the socket,
what happens? (Probably nothing very good, since the first thing the
client will do is write on it.)

>> If we do want to apply Peter's patch, I think it needs to be extended so
>> that the default behavior on sockets is the same as before, ie, no SSL.

> That seems like it is going to be added confusion; just using the
> protected socket diretory or TCP & SSL seems less error-prone.

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.

regards, tom lane