Thread: BUG #9003: Hard-coding to localhost in postmaster
The following bug has been logged on the website: Bug reference: 9003 Logged by: Paul Morie Email address: pmorie@redhat.com PostgreSQL version: 9.2.4 Operating system: RHEL Description: Currently there is a hard-coding in postgresql postmaster to bind to 'localhost'. This results in postmaster and autovacuum being broken if the user cannot bind to 127.0.0.1. Can this be configurable?
On 2014-01-27 18:31:25 +0000, pmorie@redhat.com wrote: > The following bug has been logged on the website: > > Bug reference: 9003 > Logged by: Paul Morie > Email address: pmorie@redhat.com > PostgreSQL version: 9.2.4 > Operating system: RHEL > Description: > > Currently there is a hard-coding in postgresql postmaster to bind to > 'localhost'. This results in postmaster and autovacuum being broken if the > user cannot bind to 127.0.0.1. Why would the user be unable to bind to 127.0.0.1? I.e. what's the usecase this would allow? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-01-27 18:31:25 +0000, pmorie@redhat.com wrote:
>> Currently there is a hard-coding in postgresql postmaster to bind to
>> 'localhost'. This results in postmaster and autovacuum being broken if the
>> user cannot bind to 127.0.0.1.
> Why would the user be unable to bind to 127.0.0.1? I.e. what's the
> usecase this would allow?
Is there some other preferred name for localhost? I was under the
impression that that name was required by some dusty RFC or other.
Assuming that you're speaking of the statistics collector's port, we do
not really want that to be "configurable" because there is no possible
reason for allowing it to bind to anything except the current host.
There would be a lot more potential for breakage than positive results
if we exposed a configuration knob for that.
I recall that we did debate relying on "localhost" versus hard-coding
"127.0.0.1", and rejected the latter because IPv6 might be preferred
on some systems.
regards, tom lane
Hi, On 2014-01-27 19:06:21 -0500, Paul Morie wrote: > The specific use-case I'm trying to address is within OpenShift > (www.openshift.com), where users cannot bind to localhost of > 127.0.0.1. In this case, the user needs to be able to bind to another > interface. That's an odd restriction to make. You're running out of ports on 127.0.0.1? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Andres- The specific use-case I'm trying to address is within OpenShift (www.openshift.com), where users cannot bind to localhostof 127.0.0.1. In this case, the user needs to be able to bind to another interface. P ----- Original Message ----- > From: "Andres Freund" <andres@2ndquadrant.com> > To: pmorie@redhat.com > Cc: pgsql-bugs@postgresql.org > Sent: Monday, January 27, 2014 6:20:50 PM > Subject: Re: [BUGS] BUG #9003: Hard-coding to localhost in postmaster > > On 2014-01-27 18:31:25 +0000, pmorie@redhat.com wrote: > > The following bug has been logged on the website: > > > > Bug reference: 9003 > > Logged by: Paul Morie > > Email address: pmorie@redhat.com > > PostgreSQL version: 9.2.4 > > Operating system: RHEL > > Description: > > > > Currently there is a hard-coding in postgresql postmaster to bind to > > 'localhost'. This results in postmaster and autovacuum being broken if the > > user cannot bind to 127.0.0.1. > > Why would the user be unable to bind to 127.0.0.1? I.e. what's the > usecase this would allow? > > Greetings, > > Andres Freund > > -- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services >
Hi, On 2014-01-28 10:41:49 -0500, Paul Morie wrote: > The challenge we have in openshift is that we have multiple users on a > single node who all want to bind to the same port. To deal with this, > we forbid the users from binding to 127.0.0.1 using selinux and > allocate IPs for them to bind to. Uhm. What about using network namespaces? To me this really sounds like tackling things from the wrong end. Instead of fixing the infrastructure once this way you need to adapt various pieces of software in odd ways. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-01-28 10:41:49 -0500, Paul Morie wrote:
>> The challenge we have in openshift is that we have multiple users on a
>> single node who all want to bind to the same port. To deal with this,
>> we forbid the users from binding to 127.0.0.1 using selinux and
>> allocate IPs for them to bind to.
> Uhm. What about using network namespaces?
> To me this really sounds like tackling things from the wrong
> end. Instead of fixing the infrastructure once this way you need to
> adapt various pieces of software in odd ways.
Yeah. In particular, I'd always supposed that a platform that wanted
to use some other IP address than 127.0.0.1 for loopback would also be
expected to make sure that "localhost" mapped to that other IP address.
Otherwise, there simply isn't any way to make network-using software
work except random hacks.
Frankly, I don't think you're going to get any cooperation from Postgres
in adapting to such a broken networking environment as this, and I doubt
other upstreams are going to be any more positive about it.
regards, tom lane
On Tue, Jan 28, 2014 at 11:15:54AM -0500, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On 2014-01-28 10:41:49 -0500, Paul Morie wrote: > >> The challenge we have in openshift is that we have multiple users on a > >> single node who all want to bind to the same port. To deal with this, > >> we forbid the users from binding to 127.0.0.1 using selinux and > >> allocate IPs for them to bind to. > > > Uhm. What about using network namespaces? > > > To me this really sounds like tackling things from the wrong > > end. Instead of fixing the infrastructure once this way you need to > > adapt various pieces of software in odd ways. > > Yeah. In particular, I'd always supposed that a platform that wanted > to use some other IP address than 127.0.0.1 for loopback would also be > expected to make sure that "localhost" mapped to that other IP address. > Otherwise, there simply isn't any way to make network-using software > work except random hacks. > > Frankly, I don't think you're going to get any cooperation from Postgres > in adapting to such a broken networking environment as this, and I doubt > other upstreams are going to be any more positive about it. Also, certainly other users are using Postgres and Openshift. What is different about your environment? Is it some new feature of Openshift? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Andres- The challenge we have in openshift is that we have multiple users on a single node who all want to bind to the same port. To deal with this, we forbid the users from binding to 127.0.0.1 using selinux and allocate IPs for them to bind to. Does that make sense? Thanks, Paul ----- Original Message ----- > From: "Andres Freund" <andres@2ndquadrant.com> > To: "Paul Morie" <pmorie@redhat.com> > Cc: pgsql-bugs@postgresql.org > Sent: Monday, January 27, 2014 7:12:21 PM > Subject: Re: [BUGS] BUG #9003: Hard-coding to localhost in postmaster > > Hi, > > On 2014-01-27 19:06:21 -0500, Paul Morie wrote: > > The specific use-case I'm trying to address is within OpenShift > > (www.openshift.com), where users cannot bind to localhost of > > 127.0.0.1. In this case, the user needs to be able to bind to another > > interface. > > That's an odd restriction to make. You're running out of ports on > 127.0.0.1? > > Greetings, > > Andres Freund > > -- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services >
On Tue, Jan 28, 2014 at 02:46:52PM -0500, Paul Morie wrote: > Apologies: I should have explained more of the context in my original post to this list. > I work for Red Hat on OpenShift and discovered this while investigating error messages > in the postgres logs (the bug report in OpenShift: https://bugzilla.redhat.com/show_bug.cgi?id=1024676). > Since it impacts the autovacuum functionality for our users, I wanted to see if I could > get an upstream fix. > > In OpenShift, user processes run inside a 'gear' - which has its own /etc/passwd entry, > selinux context, etc. Each gear user gets a 127.x.x.x loopback device to bind to so it > can all use the same ports like 8080 for web traffic, 5432 for postgres. That's only > possible if each gear gets its own unique loopback address. Binding to > localhost/127.0.0.1 is explicitly disallowed. > > We are not currently using network namespaces in OpenShift because they were not available > in the RHEL kernel until 6.5 (released Nov 2013). Now that they're supported, using them > in OpenShift is one of our high-priority items. > > Hope that clarifies why I would be interested in this option :) Based on your setup, why would you not DNS-map "localhost" to whatever 127.x.x.x address you gave that gear? We specifically bind to the "localhost" string and not 127.0.0.1. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
On 1/28/2014 11:51 AM, Bruce Momjian wrote: > Based on your setup, why would you not DNS-map "localhost" to whatever > 127.x.x.x address you gave that gear? We specifically bind to the > "localhost" string and not 127.0.0.1. from that bit about 'network namespaces', it sounds like they all share DNS and /etc/hosts until the latest 6.5 kernel. -- john r pierce 37N 122W somewhere on the middle of the left coast
On Tue, Jan 28, 2014 at 12:00:48PM -0800, John R Pierce wrote: > On 1/28/2014 11:51 AM, Bruce Momjian wrote: > >Based on your setup, why would you not DNS-map "localhost" to whatever > >127.x.x.x address you gave that gear? We specifically bind to the > >"localhost" string and not 127.0.0.1. > > from that bit about 'network namespaces', it sounds like they all > share DNS and /etc/hosts until the latest 6.5 kernel. Oh, I read: > We are not currently using network namespaces in OpenShift because they > were not available as meaning they have private DNS in each gear, but you might be right. I never thought you wouldn't have your own DNS in each gear. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Apologies: I should have explained more of the context in my original post to this list. I work for Red Hat on OpenShift and discovered this while investigating error messages in the postgres logs (the bug report in OpenShift: https://bugzilla.redhat.com/show_bug.cgi?id=1024676). Since it impacts the autovacuum functionality for our users, I wanted to see if I could get an upstream fix. In OpenShift, user processes run inside a 'gear' - which has its own /etc/passwd entry, selinux context, etc. Each gear user gets a 127.x.x.x loopback device to bind to so it can all use the same ports like 8080 for web traffic, 5432 for postgres. That's only possible if each gear gets its own unique loopback address. Binding to localhost/127.0.0.1 is explicitly disallowed. We are not currently using network namespaces in OpenShift because they were not available in the RHEL kernel until 6.5 (released Nov 2013). Now that they're supported, using them in OpenShift is one of our high-priority items. Hope that clarifies why I would be interested in this option :) Thanks, Paul ----- Original Message ----- > From: "Bruce Momjian" <bruce@momjian.us> > To: "Tom Lane" <tgl@sss.pgh.pa.us> > Cc: "Andres Freund" <andres@2ndquadrant.com>, "Paul Morie" <pmorie@redhat.com>, pgsql-bugs@postgresql.org > Sent: Tuesday, January 28, 2014 11:19:00 AM > Subject: Re: [BUGS] BUG #9003: Hard-coding to localhost in postmaster > > On Tue, Jan 28, 2014 at 11:15:54AM -0500, Tom Lane wrote: > > Andres Freund <andres@2ndquadrant.com> writes: > > > On 2014-01-28 10:41:49 -0500, Paul Morie wrote: > > >> The challenge we have in openshift is that we have multiple users on a > > >> single node who all want to bind to the same port. To deal with this, > > >> we forbid the users from binding to 127.0.0.1 using selinux and > > >> allocate IPs for them to bind to. > > > > > Uhm. What about using network namespaces? > > > > > To me this really sounds like tackling things from the wrong > > > end. Instead of fixing the infrastructure once this way you need to > > > adapt various pieces of software in odd ways. > > > > Yeah. In particular, I'd always supposed that a platform that wanted > > to use some other IP address than 127.0.0.1 for loopback would also be > > expected to make sure that "localhost" mapped to that other IP address. > > Otherwise, there simply isn't any way to make network-using software > > work except random hacks. > > > > Frankly, I don't think you're going to get any cooperation from Postgres > > in adapting to such a broken networking environment as this, and I doubt > > other upstreams are going to be any more positive about it. > > Also, certainly other users are using Postgres and Openshift. What is > different about your environment? Is it some new feature of Openshift? > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + Everyone has their own god. + >
On 2014-01-28 14:46:52 -0500, Paul Morie wrote: > We are not currently using network namespaces in OpenShift because they were not available > in the RHEL kernel until 6.5 (released Nov 2013). Now that they're supported, using them > in OpenShift is one of our high-priority items. Hm, I am confused. Weren't they merged in 2.6.26 or so? Well before RHEL 6? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Wed, Jan 29, 2014 at 12:02:37PM -0500, Paul Morie wrote: > > Based on your setup, why would you not DNS-map "localhost" to whatever > > 127.x.x.x address you gave that gear? We specifically bind to the > > "localhost" string and not 127.0.0.1. > > The gears do not have their own DNS. Gear processes run in regular unix accounts > and not in VMs, linux containers, etc. I am guessing you can't use a Bind configuration file to return a specific "localhost" IP address for specific gear because they don't have unique IP source addresses, e.g. you can't filter the source requests. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
> Based on your setup, why would you not DNS-map "localhost" to whatever > 127.x.x.x address you gave that gear? We specifically bind to the > "localhost" string and not 127.0.0.1. The gears do not have their own DNS. Gear processes run in regular unix accounts and not in VMs, linux containers, etc. P