Martijn van Oosterhout wrote:
> On Sat, Dec 22, 2007 at 02:21:42PM -0500, Tom Lane wrote:
>> No, we shouldn't, and if I had any authority over them I would make
>> Debian stop doing that. It amounts to a unilateral distro-specific
>> change in the protocol, and I think it makes things *less* secure,
>> because any clients who are expecting the socket to be in /tmp will be
>> easy pickings for a spoofer. Debian cannot hope to prevent that
>> scenario, because there are non-libpq-based client implementations.
>
> Well, it's worked for many years and a little late to change now. It's
> arguably safer, since only postmasters owned by "postgres" can create a
> socket in that directory, any client attempting to connect to a server
> using that directory knows it's connecting to a server owned by
> 'postgres'.
>
> I can't think of any non-libpq clients which support Unix domain
> sockets?
A different though on this - IIRC, you can at least on linux configure
firewall rules based on the uid a talking process is running as. And if
I'm not mistaken, you can fiddle something similar on Windows using the
ipsec stack (not easily, though).
This would make it impossible for a user to create something binding to
the pg port, or at least taking on said port, unless they also manage to
hack the postgres service account. And if they do that, they have full
access to datafiles and certificates and everything, so you've really
lost already in that case.
This obviously only applies to TCP sockets and not Unix sockets.
(And yes, I still consider this more of a host problem than a db problem)
//Magnus
