Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Sure. But we *do* provide a way to work around it *if you have to*: use
SSL with trusted certificates. In the large number of cases where you
*don't* need to worry about it, there's no need to add any extra overhead.
And if you're going with SSL already, the extra overhead of TCP vs Unix
sockets shouldn't matter *at all*... So I don't really see a motivation
for us to support SSL over Unix sockets, if it adds any complexity to
the code.
Well, the problem with the current behavior is that the client app can
"require SSL", but the request is silently ignored if the connection is
over Unix socket. So you might think you're secure when you aren't.
I think that the reason we don't support SSL over Unix socket is mainly
that we thought it was useless; but this discussion has exposed reasons
to use it. So I'm for just eliminating the asymmetry.
I have no problem with that. But it does seem to me that we are going
about this all wrong. The OP proposed a "solution" which was intended to
ensure at the server end that an untrusted user could not spoof the
postmaster if the postmaster were not running. Putting the onus of this
on clients seems wrong. I don't have any experience with SELinux, but my
impression is that it can be used to control who or what can open files,
sockets etc. On Linux at least this strikes me as a more productive
approach to the original problem, as it would put the solution in the
SA's hands. Maybe other Unices and Windows have similar capabilities?
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
