Re: postgresql 7.2b5 and vserver: statistics sockets - Mailing list pgsql-general

From
Subject Re: postgresql 7.2b5 and vserver: statistics sockets
Date
Msg-id Pine.LNX.4.33.0201231810250.10226-100000@mail.conostix.com
Whole thread Raw
In response to Re: postgresql 7.2b5 and vserver: statistics sockets  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: postgresql 7.2b5 and vserver: statistics sockets  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Wed, 23 Jan 2002, Tom Lane wrote:

> <postgresql@fruru.com> writes:
> > If more people encounter the same problem (it's the way vserver works,
> > there are some good arguments on why not to make 127.0.0.1 available)
>
> Uh ... what are they?  We're willing to listen to reasonable arguments
> why that needs to be configurable.

All the vservers on a physical machine actually run on the same kernel and
therefore share the same loopback interface.  Every vserver has one IP
address (alias) which it can use as its own.  So using the alias we know
in advance which vserver (if any) we send a packet to.  Using 127.0.0.1 we
don't, since if we don't limit the use of this address by the vservers,
everyone (including people in a "hostile" vserver on the same physical
machine) could bind to it and interfere with our vserver -> Not So
Good(tm).

Having multiple lo interfaces, one per vserver, on the same "real"
kernel could be a solution were it not that this quickly becomes a mess
(i see some routing issues)

Of course, when binding the stats port to something else than 127.0.0.1
one needs to implement a minimum of firewalling if one doesn't trust the
network (or the other vservers).  But this isn't really new and I hope
anyone in such a case already has their FW up and running.

Hope this helps,
Tycho Fruru






pgsql-general by date:

Previous
From: "Johnson, Shaunn"
Date:
Subject: Re: pad column with leading zeros or space
Next
From: Florian Wunderlich
Date:
Subject: persistent portals/cursors (between transactions)