postgresql 7.2b5 and vserver: statistics sockets

On Wed, 23 Jan 2002, Roderick A. Anderson wrote:

Try creating a v_postgresql init file (attached example) and disabling
postgresql in the main server. PostgreSQL binds to a port like the
other v_* services do.

There is no postgres in the main server. The only postgres (should) run
in a vserver. The problem is that there seems to be a bind to IP address
127.0.0.1 hardcoded in the postgresql source (see
/postgresql-7.2b5/src/backend/postmaster/pgstat.c) which obviously does
not work in the vserver (exactly because it is already ip limited!)

BTW: i have edited postgresql.conf to have the postmaster bind to the
right IP address. It is the statistics collection process that screws up
in my case (no 127.0.0.1 available).

Anyone has a patch handy by accident ? ;-)

I might just change the behavior to "bind to any port and you better have
a good firewall to protect you" ...

Regards,
Tycho

<postgresql@fruru.com> writes:

so the bind on address 127.0.0.1 (for the statistics process) is not
allowed (which is correct). How can I change this value ?

You don't. I see nothing wrong with the code's behavior; it's your
jail that's being too restrictive.

regards, tom lane

On Wed, 23 Jan 2002 postgresql@fruru.com wrote:

Hello,

I'm using vserver (http://www.solucorp.qc.ca/miscprj/s_context.hc)
together with postgresql 7.2b5.

For those who aren't familiar with vserver, it is sort of a improved
chroot jail where port bindings and process signals are also restricted.

When starting postgresql in such a vserver, i get the following error :
(using strace on the postmaster)

Try creating a v_postgresql init file (attached example) and disabling
postgresql in the main server. PostgreSQL binds to a port like the
other v_* services do.

Cheers,
Rod
--
Let Accuracy Triumph Over Victory

Zetetic Institute
"David's Sling"
Marc Stiegler

I know it is pathetic to reply to one's own mail but hey ...

On Wed, 23 Jan 2002 postgresql@fruru.com wrote:

Anyone has a patch handy by accident ? ;-)

I might just change the behavior to "bind to any port and you better have
a good firewall to protect you" ...

when binding to the 0.0.0.0 address (or the address given to the vserver)
everything is shiny and rosy. I can live with having to patch (as there
is not much enthousiasm for getting this behaviour configurable) postgres
manually for this.

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) I
can come up with a cleaner solution - like a configuration directive or
something.

Thanks for the feedback,
Tycho

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

regards, tom lane

<postgresql@fruru.com> writes:

I know it is pathetic to reply to one's own mail but hey ...

Hey, we all have to do it every once in a while. ;)

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) I
can come up with a cleaner solution - like a configuration directive or
something.

If you want your fix in the main tree that's probably what you'll need
to do. I suggest you post to -hackers outlining the problem and your
proposed solution--they may be willing to accept a patch once 7.3 gets
started.

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863

On Wed, 23 Jan 2002 postgresql@fruru.com wrote:

On Wed, 23 Jan 2002, Roderick A. Anderson wrote:

There is no postgres in the main server. The only postgres (should) run
in a vserver. The problem is that there seems to be a bind to IP address
127.0.0.1 hardcoded in the postgresql source (see
/postgresql-7.2b5/src/backend/postmaster/pgstat.c) which obviously does
not work in the vserver (exactly because it is already ip limited!)

OOPS. My solution to my problem. I've look at what documentation
there is (a brief play-around in the vserver documentation) and will
have to contact Jacques about this.

Cheers,
Rod
--
Let Accuracy Triumph Over Victory

Zetetic Institute
"David's Sling"
Marc Stiegler

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

<postgresql@fruru.com> writes:

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

That might be a good argument in general, but it does not apply to
Postgres' use of 127.0.0.1, because we bind that socket to its own
address, so only packets out of the same socket will be received.
(Without this, the statistics setup would be quite insecure in the
normal non-vserver case.) We don't really care whether other vservers
are using other 127.0.0.1 ports.

I'm still of the opinion that the blame for insufficient configurability
should be placed on vserver not Postgres; vserver should have an option
to let you use 127.0.0.1.

regards, tom lane

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

That might be a good argument in general, but it does not apply to
Postgres' use of 127.0.0.1, because we bind that socket to its own
address, so only packets out of the same socket will be received.

What you're saying is that it shouldn't really matter whether you use
127.0.0.1, the ipv6 ::1 or another ipv4 or 6 address (but that's another
can of worms :-).

Anyway, the problem is pinpointed and solved (for me).

Regards,
Tycho

--
Tycho Fruru tycho.fruru@conostix.com
Users' impressions of different operating systems, expressed as emoticons:
Linux: :)
Windows: XP

<postgresql@fruru.com> writes:

That might be a good argument in general, but it does not apply to
Postgres' use of 127.0.0.1, because we bind that socket to its own
address, so only packets out of the same socket will be received.

What you're saying is that it shouldn't really matter whether you use
127.0.0.1, the ipv6 ::1 or another ipv4 or 6 address (but that's another
can of worms :-).

As long as it's routed to our own machine, no it doesn't matter. But
AFAIK there is no other generally-accepted loopback address.

regards, tom lane

"p" == postgresql <postgresql@fruru.com> writes:

p> so the bind on address 127.0.0.1 (for the statistics process) is not
p> allowed (which is correct). How can I change this value ? (If no other
p> possibility is available, I'm going to change the source)

The vserver application needs to be fixed to re-route calls to bind
localhost IP address to the IP address for that jail. FreeBSD's jail
system does this. It is unreasonable to expect a program not to have
access to 127.0.0.1.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

At 12:08 PM 23-01-2002 -0500, 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.

Just like to point out that if IP forwarding is enabled on a target host,
other hosts on the same network could access 127.0.0.1 on that target host
(or any interface for that matter).

For some target operating systems that may still work even if IP forwarding
is off.

e.g. use certain source operating systems, bring down 127.x.x.x if present,
add the route to 127.0.0.1 using gateway = target host adjacent IP. Now
ping or telnet 127.0.0.1.

Cheerio,
Link.

On Thu, Jan 24, 2002 at 04:52:29PM +0800,
Lincoln Yeoh <lyeoh@pop.jaring.my> wrote:

Just like to point out that if IP forwarding is enabled on a target host,
other hosts on the same network could access 127.0.0.1 on that target host
(or any interface for that matter).

For some target operating systems that may still work even if IP forwarding
is off.

Except that well configured hosts should only accept traffic on external
interfaces that makes sense. And typically traffic addressed to 127.*.*.*
shouldn't be accepted from an external interface.