Re: We do not need pg_promote_v4_to_v6_addr/mask
От | Andrew Dunstan |
---|---|
Тема | Re: We do not need pg_promote_v4_to_v6_addr/mask |
Дата | |
Msg-id | 54E2A654.9040802@dunslane.net обсуждение исходный текст |
Ответ на | Re: We do not need pg_promote_v4_to_v6_addr/mask (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: We do not need pg_promote_v4_to_v6_addr/mask
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: