Re: Brokenness in parsing of pg_hba.conf

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Brokenness in parsing of pg_hba.conf
Дата
Msg-id 3FFB8273.1020202@dunslane.net
обсуждение исходный текст
Ответ на Brokenness in parsing of pg_hba.conf  ("Alex J. Avriette" <alex@posixnap.net>)
Ответы Re: Brokenness in parsing of pg_hba.conf  ("Alex J. Avriette" <alex@posixnap.net>)
Re: Brokenness in parsing of pg_hba.conf  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Brokenness in parsing of pg_hba.conf  (Kurt Roeckx <Q@ping.be>)
Список pgsql-hackers
A few points.

1. clarification of my IRC comment: A quick examination seems to shaw 
that we use the native getaddrinfo() where it exists, otherwise we use 
our own, which in turn calls inet_ntoa().
2. ip6 has a well defined standard for abbreviation, and is quite 
important to have since ip6 addresses would otherwise often be tediously 
long. I haven't found a comparable standard for abbreviating IP4 
addresses. There appears to be a convention relying on behaviour of 
inet_aton, and perhaps hallowed by history, but by any measure surely 
brain dead and counter intuitive. Why would a.b.c become a.b.0.c and a.b 
become a.0.0.b? On Linux it is not even documented. See the email from 
Paul Vixie cited below for futher gory details, including a citation of 
rfc1208 that specifies exactly 4 parts for a dotted notation. It's not 
surprising that he starts one sentence thus:  "Now, before you laugh so 
hard you fall out of your collective seats,".
3. Maybe some people are used to it. In around 15 years of using and 
administering Unix I haven't tripped over this before, so I suspect it's 
probably not a huge problem :-)
4. My personal preference would be that if any change is made it would 
be to insist on an unabbreviated dotted quad for ip4. Alternatively, we 
need to make sure that whatever we do is consistent. That might not be 
possible, however, if different platforms or different library calls 
behave differently.

cheers

andrew



Alex J. Avriette wrote:

>So one of the client machines for one of my databases at work resides
>on 10.128.0.45. I had to enter something in pg_hba.conf for it today,
>as we're bringing this database up. We have a lot of 10/8 subnets, and
>I use it at home, so I'm accustomed to just using 10.128.45 for the IP.
>Strangely, however, postgres refused to acknowledge the host when it
>connected. I checked it again, and sure enough, the IP was right. It
>turns out that postgres parses pg_hba.conf in an unexpected way -- it
>does not accept "abbreviated" ip4 addresses (note that this is common
>in both ip4 and ip6).
>
>In the manpage for inet_aton, we see:
>
>INTERNET ADDRESSES (IP VERSION 4)
>     Values specified using the `.' notation take one of the following forms:
>
>           a.b.c.d
>           a.b.c
>           a.b
>           a
>
>     When four parts are specified, each is interpreted as a byte of data and
>     assigned, from left to right, to the four bytes of an Internet address.
>
>Andrew Dunstan on IRC mentioned that the parser is using the native
>getaddrinfo. I'm not sure if there are any advantages to this; I've
>said before that I'm really not a C guy.
>
>Paul Vixie had this to say about the convention:
>
>  
>
>>What this man page is trying to tell you is that BSD users have
>>historically said "10.73" rather than "10.0.0.73" because they both
>>worked any place where either worked. This includes DNS primary zone
>>files, by the way.
>>
>>
>>I am pretty much assuming that the IETF does not want to standardize
>>this BSD practice, and that we ought not to accept ::10.73 as
>>equivilent to the longer ::10.0.0.73, especially given that the
>>degenerate case given in that man page would be ambiguous with respect
>>to ::1234, a valid RFC1884 address specifier whose low order 16 bits
>>are hexadecimal 1234 rather than decimal 1234.
>>
>>
>>However, that's only _my_ assumption, and some other implementor may
>>feel differently. In fact some other implementor of RFC 1884 might
>>decide to just call inet_aton() for parsing that IPv4 "dotted quad",
>>which is what I almost did.
>>    
>>
>
>The original article can be found here:
>
>http://www.cs-ipv6.lancs.ac.uk/ipv6/mail-archive/IPng/1996-06/0037.html
>
>I think it is important that postgres behave as expected when handing
>it a properly formatted ip4 address. However, I'm aware that many
>people don't even realize this is a valid address. As such, I won't
>lose any sleep over it, but I thought I'd mention it, since it
>surprised me today.
>
>Thoughts?
>
>Alex
>
>--
>alex@posixnap.net
>Alex J. Avriette, Solaris Frobnosticator
>"You can get much farther with a kind word and a gun than you can with a kind word alone." - Al Capone
>
>---------------------------(end of broadcast)---------------------------
>TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
>  
>



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: processing of unknown datatype
Следующее
От: Tom Lane
Дата:
Сообщение: Re: processing of unknown datatype