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.
> >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.
-O
