pgsql: Clarify description of CIDR-address column of pg_hba.conf, to

Started by Nonameabout 19 years ago6 messages
#1Noname
tgl@postgresql.org

Log Message:
-----------
Clarify description of CIDR-address column of pg_hba.conf, to discourage
people from trying notations like '10.6/16', which is accepted but does
not mean what you probably think. Per example from Paul Forgey.

Modified Files:
--------------
pgsql/doc/src/sgml:
client-auth.sgml (r1.94 -> r1.95)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/client-auth.sgml.diff?r1=1.94&r2=1.95)

#2Andrew Dunstan
andrew@dunslane.net
In reply to: Noname (#1)
Re: pgsql: Clarify description of CIDR-address column

Tom Lane wrote:

Log Message:
-----------
Clarify description of CIDR-address column of pg_hba.conf, to discourage
people from trying notations like '10.6/16', which is accepted but does
not mean what you probably think. Per example from Paul Forgey.

Isn't the real problem here that 10.6 doesn't mean what you probably think?

cheers

andrew

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Dunstan (#2)
Re: [COMMITTERS] pgsql: Clarify description of CIDR-address column

"Andrew Dunstan" <andrew@dunslane.net> writes:

Tom Lane wrote:

Clarify description of CIDR-address column of pg_hba.conf, to discourage
people from trying notations like '10.6/16', which is accepted but does
not mean what you probably think. Per example from Paul Forgey.

Isn't the real problem here that 10.6 doesn't mean what you probably think?

If you're proposing that we change the behavior of inet_aton(), I don't
think that's much of a solution, since then people who do remember the
old notation ... or recognize the analogy to IPv6 abbreviations, which
are not a lot different ... would get burnt. We can't do it anyway on
most modern platforms, unless we want to replace all of getaddrinfo()
which seems pretty unappealing.

regards, tom lane

#4Florian G. Pflug
fgp@phlo.org
In reply to: Tom Lane (#3)
Re: [COMMITTERS] pgsql: Clarify description of CIDR-address

Tom Lane wrote:

"Andrew Dunstan" <andrew@dunslane.net> writes:

Tom Lane wrote:

Clarify description of CIDR-address column of pg_hba.conf, to discourage
people from trying notations like '10.6/16', which is accepted but does
not mean what you probably think. Per example from Paul Forgey.

Isn't the real problem here that 10.6 doesn't mean what you probably think?

I'm curious now - what _does_ 10.6/16 mean? I can't imagine any sensible
meaning apart from 10.6.0.0/16...

Please enlighten me.

greetings, Florian Pflug

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Florian G. Pflug (#4)
Re: [COMMITTERS] pgsql: Clarify description of CIDR-address column

"Florian G. Pflug" <fgp@phlo.org> writes:

"Andrew Dunstan" <andrew@dunslane.net> writes:

Isn't the real problem here that 10.6 doesn't mean what you probably think?

I'm curious now - what _does_ 10.6/16 mean? I can't imagine any sensible
meaning apart from 10.6.0.0/16...

10.6 means the same as 10.0.0.6 --- see src/port/inet_aton.c.
This has been discussed before:
http://archives.postgresql.org/pgsql-hackers/2004-01/msg00132.php

My feeling is the same as it was then, ie, we are not in the business of
second-guessing standard library routines.

regards, tom lane

#6Andrew Dunstan
andrew@dunslane.net
In reply to: Tom Lane (#3)
Re: [COMMITTERS] pgsql: Clarify description of

Tom Lane wrote:

"Andrew Dunstan" <andrew@dunslane.net> writes:

Tom Lane wrote:

Clarify description of CIDR-address column of pg_hba.conf, to
discourage
people from trying notations like '10.6/16', which is accepted but does
not mean what you probably think. Per example from Paul Forgey.

Isn't the real problem here that 10.6 doesn't mean what you probably
think?

If you're proposing that we change the behavior of inet_aton(), I don't
think that's much of a solution, since then people who do remember the
old notation ... or recognize the analogy to IPv6 abbreviations, which
are not a lot different ... would get burnt. We can't do it anyway on
most modern platforms, unless we want to replace all of getaddrinfo()
which seems pretty unappealing.

No, I'm only suggesting that the confusion has much to do with the use of
abbreviated addresses and not much to do with use of CIDR masks. If we are
worried about the confusion we should spell out the problem explicitly.

cheers

andrew