Re: Specification of "/" in the host name (for Unix socket support)

From: Paul Thomas <paul(at)tmsl(dot)demon(dot)co(dot)uk>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: "pgsql-jdbc (at) postgresql (dot) org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Specification of "/" in the host name (for Unix socket support)
Date: 2003-09-17 14:14:10
Message-ID: 20030917151410.A28540@bacon
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 |
+------------------------------+---------------------------------------------+

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message David Esposito 2003-09-17 14:22:38 JDBC Encoding conversion bug
Previous Message David Esposito 2003-09-17 14:12:12 JDBC Encoding conversion bug