Re: Spoofing as the postmaster

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