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)
Список 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 по дате отправления:

Предыдущее
От: Barry Lind
Дата:
Сообщение: Re: Error Codes
Следующее
От: "David Esposito"
Дата:
Сообщение: JDBC Encoding conversion bug