Re: TCP/IP with 7.4 beta2 broken?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TCP/IP with 7.4 beta2 broken?
Date: 2003-09-05 07:16:54
Message-ID: 3F583866.8040706@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2003-09-05 07:24:49 Re: [PATCHES] Warning for missing createlang
Previous Message Shridhar Daithankar 2003-09-05 07:12:56 Re: Prelimiary DBT-2 Test results