Обсуждение: 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