Brokenness in parsing of pg_hba.conf

From: "Alex J(dot) Avriette" <alex(at)posixnap(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Brokenness in parsing of pg_hba.conf
Date: 2004-01-07 02:37:14
Message-ID: 20040107023714.GA3739@posixnap.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)posixnap(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Cramer 2004-01-07 03:46:10 Re: processing of unknown datatype
Previous Message Dave Cramer 2004-01-07 02:31:51 Re: processing of unknown datatype