Re: TCP/IP with 7.4 beta2 broken? - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: TCP/IP with 7.4 beta2 broken?
Date
Msg-id 3F583866.8040706@dunslane.net
Whole thread Raw
In response to Re: TCP/IP with 7.4 beta2 broken?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: TCP/IP with 7.4 beta2 broken?
Re: TCP/IP with 7.4 beta2 broken?
List pgsql-hackers

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>There's a lot of confusion around :-) Let me see if I can disentangle 
>>some of it.
>>    
>>
>
>  
>
>>People seem to want two things:
>>1. if ip4 is being tunneled over ip6 as it is in most Linux 
>>distributions, match a corresponding 'host*' line with an ip4 address.
>>2. enable local connections of whatever flavor by default.
>>    
>>
>
>Sounds right to me.
>
>  
>
>>Andreas has addressed item 1. I suggested an approach to item 2. The 
>>only alternative I can see is to allow ip4-only postmasters to recognize 
>>and silently drop ip6 'host*' lines. I don't like the idea of silently 
>>ignoring config lines - it seems dangerous to me. Suggestions of having 
>>initdb or something similar conditionally set the default pg_hba.conf 
>>also strike me as impractical and fragile.
>>    
>>
>
>Bruce and I were just discussing this on the phone.  It seems we have
>two basic approaches to problem #2.  Either we hack the postmaster so
>that it will swallow IPv6 addresses in pg_hba.conf even without any real
>IPv6 support, or we make the default pg_hba.conf contents different.
>Neither of these is real pretty, but I am leaning to the second, because
>I agree with your feeling that silently ignoring config lines is a bad
>idea.
>
>I do not believe that there's anything fragile about having initdb make
>this adjustment.  We can arrange for initdb to be aware of the HAVE_IPV6
>compilation flag (its value can be inserted when initdb is made from
>initdb.sh, the same way some other configuration items are already
>inserted into the script).  As far as I can see, HAVE_IPV6 is exactly
>what we want to look at to decide whether to put "::1" into pg_hba.conf.
>If we HAVE_IPV6, then the postmaster can parse "::1".  Whether the
>kernel has IPv6 enabled doesn't matter --- if not, it would only mean
>that the postmaster will never actually see a connection from "::1";
>so the pg_hba.conf entry will never be matched.  But it won't hurt
>anything.  Conversely, if we don't HAVE_IPV6, we can't parse "::1"
>... but we don't need to, even if the kernel has IPv6, because such a
>postmaster won't try to listen for AF_INET6 connections.
>
>  
>
OK, now we are getting somewhere. I see that this would work. It's a bit 
ugly, though - with this plan the sample file in both CVS and the 
installation won't necessarily be what actually get put in place. What 
if some clever installer/administrator deliberately alters their 
installed sample file?

Could we get the configure script to do it instead, since it too should 
know about ip6 capability? (I guess then we'd have 
pg_hba.conf.sample.in). That strikes me as being a lot cleaner.

andrew





pgsql-hackers by date:

Previous
From: "Shridhar Daithankar"
Date:
Subject: Re: Prelimiary DBT-2 Test results
Next
From: Andrew Dunstan
Date:
Subject: Re: [PATCHES] Warning for missing createlang