Обсуждение: postgresql 7.2b5 and vserver: statistics sockets
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) ---- getpid() = 6609 unlink("/var/ipfc/database//global/pgstat.stat") = -1 ENOENT (No such file or directory) socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5 bind(5, {sin_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}}, 16) = -1 EADDRNOTAVAIL (Cannot assign requested address) dup(2) = 6 fcntl64(0x6, 0x3, 0x6, 0) = 32770 fstat64(6, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 _llseek(6, 0, 0xbfffeca0, SEEK_CUR) = -1 ESPIPE (Illegal seek) write(6, "PGSTAT: bind(2): Cannot assign r"..., 49PGSTAT: bind(2): Cannot assign requested address ) = 49 close(6) = 0 ---- 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 ? (If no other possibility is available, I'm going to change the source) Best regards, Tycho Fruru -- Tycho Fruru tycho.fruru@conostix.com Users' impressions of different operating systems, expressed as emoticons: Linux: :) Windows: XP
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
Вложения
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
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.