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)
|
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: