Обсуждение: We do not need pg_promote_v4_to_v6_addr/mask

We have some code in the server that attempts to match IPv4 address
entries in pg_hba.conf to incoming connections that are in IPv6 protocol
but have addresses in the range ::ffff:xxxx:xxxx (the IPv4-in-IPv6
subrange).  As revealed by today's bug report from Hugo Osvaldo Barrera,
this code has been broken since commit f3aec2c7f51904e7 (shipped in 9.0),
as a result of sloppiness with a memcpy() source address.  How is it that
nobody noticed?

Experimentation with a RHEL6 box says that at least on Linux kernels,
such cases never arise because the kernel will not report such an address
to the postmaster.  You can ask to connect with an address like that,
viz "psql -h ::ffff:7f00:0001 ..." but what the kernel will tell the
postmaster is the client address is IPv4-style 127.0.0.1.

It's certainly possible that on other platforms there is a visible
distinction between ::ffff:7f00:0001 and 127.0.0.1, but the lack of field
complaints about this bug suggests that there isn't.

Moreover: suppose that on hypothetical platform X the kernel does report
such client addresses differently.  Anybody on such a platform who's used
both types of client addresses with any 9.x release must have ended up
making different pg_hba.conf entries for the two cases.  It's not
impossible that they chose to make the entries meaningfully different;
in which case they will not thank us for "fixing" the code so that the
distinction vanishes again.  If your platform thinks these are different
addresses then you probably do too.

In short, then, I'm having second thoughts about the quick-hack patch
I committed earlier to fix the memcpy thinko.  On platforms where it has
any effect at all, that effect will be to make a subtle and perhaps
security-relevant change to the interpretation of pg_hba.conf entries,
changing what the postmaster has treated them as meaning since 9.0.0.
That doesn't sound like the kind of thing we want to do in minor releases.

Therefore, I now think what we ought to do, both in HEAD and in the back
branches, is rip out the "#ifdef HAVE_IPV6" stanza in check_ip(), delete
pg_promote_v4_to_v6_addr and pg_promote_v4_to_v6_mask which will thereby
become unused, and remove the single sentence in the manual that claims
that IPv4-in-IPv6 connections will match IPv4 pg_hba.conf entries.  This
amounts to accepting our behavior since 9.0 as being correct.  If there
was ever a live need for the older behavior, its time has evidently
passed.
        regards, tom lane

I wrote:
> We have some code in the server that attempts to match IPv4 address
> entries in pg_hba.conf to incoming connections that are in IPv6 protocol
> but have addresses in the range ::ffff:xxxx:xxxx (the IPv4-in-IPv6
> subrange).  As revealed by today's bug report from Hugo Osvaldo Barrera,
> this code has been broken since commit f3aec2c7f51904e7 (shipped in 9.0),
> as a result of sloppiness with a memcpy() source address.  How is it that
> nobody noticed?

BTW, a bit of digging in the git logs and mail archives says that the code
in question was originally added in 7.4 (commit 3c9bb8886df7d56a), in
response to this discussion:
http://www.postgresql.org/message-id/flat/200309012156.05874.t.maekitalo@epgmbh.de

So back in 2003 there were Linux boxes that actively transformed IPv4
connection addresses to ::ffff:xxxx:xxxx format.  Current Linux behavior
is the exact opposite: even if you try to say ::ffff:xxxx:xxxx in a
connection request, IPv4 is what comes out the other end.  I find the same
on current OS X btw.  So I'm definitely now of the opinion that this is a
workaround for a long-deceased Linux kernel bug, and not something we need
to continue^X^X^Xresume supporting.
        regards, tom lane

On 02/16/2015 09:07 PM, Tom Lane wrote:
> I wrote:
>> We have some code in the server that attempts to match IPv4 address
>> entries in pg_hba.conf to incoming connections that are in IPv6 protocol
>> but have addresses in the range ::ffff:xxxx:xxxx (the IPv4-in-IPv6
>> subrange).  As revealed by today's bug report from Hugo Osvaldo Barrera,
>> this code has been broken since commit f3aec2c7f51904e7 (shipped in 9.0),
>> as a result of sloppiness with a memcpy() source address.  How is it that
>> nobody noticed?
> BTW, a bit of digging in the git logs and mail archives says that the code
> in question was originally added in 7.4 (commit 3c9bb8886df7d56a), in
> response to this discussion:
> http://www.postgresql.org/message-id/flat/200309012156.05874.t.maekitalo@epgmbh.de
>
> So back in 2003 there were Linux boxes that actively transformed IPv4
> connection addresses to ::ffff:xxxx:xxxx format.  Current Linux behavior
> is the exact opposite: even if you try to say ::ffff:xxxx:xxxx in a
> connection request, IPv4 is what comes out the other end.  I find the same
> on current OS X btw.  So I'm definitely now of the opinion that this is a
> workaround for a long-deceased Linux kernel bug, and not something we need
> to continue^X^X^Xresume supporting.
>
>             

Wow, talk about a walk down memory lane. Apparently that thread 
triggered my rewrite of initdb - I'd totally forgotten that.

The proposed course sounds reasonable enough.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> On 02/16/2015 09:07 PM, Tom Lane wrote:
>> BTW, a bit of digging in the git logs and mail archives says that the code
>> in question was originally added in 7.4 (commit 3c9bb8886df7d56a), in
>> response to this discussion:
>> http://www.postgresql.org/message-id/flat/200309012156.05874.t.maekitalo@epgmbh.de

> Wow, talk about a walk down memory lane.

Tell me about it ;-).  I was entirely astonished to discover that the
original author of the promote_v4_to_v6 code was moi.
        regards, tom lane