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

Поиск
Список
Период
Сортировка
Искать
От
Paul Thomas
Тема
Re: Specification of "/" in the host name (for Unix socket support)
Дата
Msg-id
20030917151410.A28540@bacon
Список
Дерево обсуждения
Specification of "/" in the host name (for Unix socket support) Deepak Bhole <dbhole@redhat.com>
Re: Specification of "/" in the host name (for Unix socket support) Paul Thomas <paul@tmsl.demon.co.uk>
Re: Specification of "/" in the host name (for Unix socket support) Tom Lane <tgl@sss.pgh.pa.us>
Re: Specification of "/" in the host name (for Unix socket support) Oliver Jowett <oliver@opencloud.com>
Re: Specification of "/" in the host name (for Unix socket Barry Lind <blind@xythos.com>
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 по дате отправления
От: Barry Lind
Дата:
Сообщение: Re: Error Codes
От: David Esposito
Дата:
Сообщение: JDBC Encoding conversion bug
FAQ