Re: Specification of "/" in the host name (for Unix socket support) - Mailing list pgsql-jdbc

From Paul Thomas
Subject Re: Specification of "/" in the host name (for Unix socket support)
Date
Msg-id 20030917151410.A28540@bacon
Whole thread Raw
In response to Specification of "/" in the host name (for Unix socket support)  (Deepak Bhole <dbhole@redhat.com>)
Responses Re: Specification of "/" in the host name (for Unix socket support)  (Oliver Jowett <oliver@opencloud.com>)
List pgsql-jdbc
On 16/09/2003 23:29 Oliver Jowett wrote:
> On Tue, Sep 16, 2003 at 02:31:00PM +0100, Paul Thomas wrote:
>
> > >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.
> >
> > If your firewall goes wrong, I think you've got more fundamental
> problems
> > that exposing port 5432! As for configuring, even a simple tool like
> > Lokkit will do the job.
>
> Sorry, I think you missed my point. Firewalls do go wrong because of
> everything from admins making mistakes to bugs in the kernel. Relying on
> a
> firewall as your only layer of security means that only that firewall has
> to
> fail before you're exposed. Better to avoid the reliance on the firewall
> in
> the first place; you'll probably have the firewall anyway for other
> reasons,
> but at least when the firewall fails you still have another layer of
> protection (the need to gain a local user on the host itself) protecting
> your DB. It's the whole "if you don't need service X, don't run it at
> all"
> argument.

Firewall + ACL <> single layer! I suppose the rest of it depends on
whether or not you're pitching a system to be idiot-proof. Personally, I
don't regard Unix Sysadmin as the ideal career for an idiot and I have
little (make that zero) sympathy for companies that do ;)

>
> > >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.
> > >
> >
> > Well, if all of this is a must-have then Java is probably the wrong
> > language to use.
>
> Why, exactly? It sounds all do-able (and not too painful, either) to me.

I don't subscribe to the view that just because something is do-able means
that doing it is necessarily a wise thing. That way lies the madness of
feature-bloat. Who is going to maintain the JNI code? ATM, the JDBC driver
only requires Java knowledge. Add JNI and a whole new skill set is
required. All-in-all, I think the long-term pain could be a lot worse that
you currently believe.

--
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for the Smaller
Business |
| Computer Consultants         |
http://www.thomas-micro-systems-ltd.co.uk   |
+------------------------------+---------------------------------------------+


pgsql-jdbc by date:

Previous
From: Barry Lind
Date:
Subject: Re: Error Codes
Next
From: "David Esposito"
Date:
Subject: JDBC Encoding conversion bug