Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> 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