On Sat, Sep 13, 2003 at 05:28:03PM +0100, Paul Thomas wrote:
> >> Get real. If Red Hat want to improve the JDBC driver, the ability to
> >> properly use server side prepared statements from a JDBC connection
> >pool
> >> would give a massively bigger performance gain that anything you
> >possibly
> >> ever get between tcp/ip and unix sockets.
> >
> >Deepak did not state or imply that the motivation for this was
> >performance.
> >Actually, it's security: lots of people prefer to run their PG servers
> >with no open TCP ports at all. So it would be good if JDBC could talk
> >to such a server.
>
> You can hide the port from the outside world with a firewall and configure
> PostgreSQL to only accept tcp/ip connections for 127.0.0.1. And if packet
> sniffing on the loopback interface is a concern, is SSL not secure enough?
> Having said that, I'm not sure if the JDBC driver supports SSL ATM but
> even without it the security argument (as opposed to a dogmatic policy
> stance) looks very weak to me which is why I initially discounted it.
The current driver does support SSL. I'm not sure what certificate
management is like under this setup, but from past SSL experiences it's
going to be "interesting".
However, the simple solution to "I don't want the outside world to see the
server" is "don't listen on TCP/IP, then". Firewalls and tweaking
postgresql's host-based ACLs would work .. if configured and maintained
correctly .. but they are hardly the simplest solution and are more likely
to go wrong.
Also user authentication becomes interesting if you want to do access
control based on the local user's identity (quite likely when you're running
the client on the same machine as the server). You're going to have to run
an ident server at a minimum (more stuff to configure, firewall, and
maintain, and another point of failure as the DB relies on it). Unix sockets
can use SCM_CREDENTIALS to pass user information in a much simpler way. And
you can set filesystem-based (user/group) permissions on a unix socket,
something you can't do with a TCP/IP listener.
-O
