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 |
+------------------------------+---------------------------------------------+
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 |