Thread: 7.4.3 & 8.0.0beta1 + Solaris 9: default pg_hba.conf breaks
8.0.0beta1 tarball built with gcc 3.2.3 under Solaris 9 on a E250 (ultrasparc). I see the same bug as described in http://archives.postgresql.org/pgsql-admin/2004-05/msg00248.php: a mask of 255.255.255.255 in pg_hba.conf is rejected with > LOG: invalid IP mask "255.255.255.255" in pg_hba.conf file line 65: host/servname not known This also breaks in the same way (with a less useful error message) under 7.4.3. Per http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20063, adding 'dns' to the hosts lookup order in /etc/nsswitch.conf fixes the problem, as does using any other mask but 255.255.255.255. Since the default config now allows TCP/IP connections from localhost, maybe we should tweak the default pg_hba.conf to work around this problem? (e.g. use the /32 syntax which works ok) -O
Oliver Jowett <oliver@opencloud.com> writes:
> Since the default config now allows TCP/IP connections from localhost,
> maybe we should tweak the default pg_hba.conf to work around this
> problem? (e.g. use the /32 syntax which works ok)
Maybe we should press Sun to fix their bugs?
Until M$, Solaris was the top of the list of platforms with known bugs
that adversely affected Postgres; many of them bugs that were well known
through multiple Solaris releases. We just last week worked around a
Solaris bug that was publicly reported in 1995, for crissakes.
For me, Solaris would be the second-from-last platform choice. If
they want to get out of the cellar, they are going to have to work
harder. Not expect me to work around more and more of their bugs.
regards, tom lane
Tom Lane wrote: > Oliver Jowett <oliver@opencloud.com> writes: > >>Since the default config now allows TCP/IP connections from localhost, >>maybe we should tweak the default pg_hba.conf to work around this >>problem? (e.g. use the /32 syntax which works ok) > > > Maybe we should press Sun to fix their bugs? Well, I can't argue with that. (it must be said that the solaris 9 install I am using is pretty out of date -- this problem may well be fixed by a later solaris patch) > For me, Solaris would be the second-from-last platform choice. If > they want to get out of the cellar, they are going to have to work > harder. Not expect me to work around more and more of their bugs. I'm happy to put together the patch if you like. If it's not in the official codebase, I'll end up applying a patch when building our local packages anyway.. -O
Tom Lane wrote: > Oliver Jowett <oliver@opencloud.com> writes: > > Since the default config now allows TCP/IP connections from localhost, > > maybe we should tweak the default pg_hba.conf to work around this > > problem? (e.g. use the /32 syntax which works ok) > > Maybe we should press Sun to fix their bugs? > > Until M$, Solaris was the top of the list of platforms with known bugs > that adversely affected Postgres; many of them bugs that were well known > through multiple Solaris releases. We just last week worked around a > Solaris bug that was publicly reported in 1995, for crissakes. > > For me, Solaris would be the second-from-last platform choice. If > they want to get out of the cellar, they are going to have to work > harder. Not expect me to work around more and more of their bugs. Agreed, but from a clarity perspective, are we better moving to the CIDR format for hostnames in pg_hba.conf anyway? I know CIDR is for networks, not hosts though. Also, I think we would accept a patch that modified pg_hba.conf for Solaris only that made this change. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Agreed, but from a clarity perspective, are we better moving to the CIDR
> format for hostnames in pg_hba.conf anyway?
Possibly --- it'd be easier to sell on that argument anyway ;-)
> Also, I think we would accept a patch that modified pg_hba.conf for
> Solaris only that made this change.
That seems like the worst of all possible worlds. Difficult to do *and*
confusing for users, since on Solaris the sample file would no longer
match the documentation.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Agreed, but from a clarity perspective, are we better moving to the CIDR > > format for hostnames in pg_hba.conf anyway? > > Possibly --- it'd be easier to sell on that argument anyway ;-) > > > Also, I think we would accept a patch that modified pg_hba.conf for > > Solaris only that made this change. > > That seems like the worst of all possible worlds. Difficult to do *and* > confusing for users, since on Solaris the sample file would no longer > match the documentation. True, but at least it would work. Are they saying the masks don't work at all? Why haven't we heard this before? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> True, but at least it would work. Are they saying the masks don't work
> at all? Why haven't we heard this before?
The specific case of mask = all ones has got a problem (and I think
there are some other conditions involved too). We have heard reports
of this before, IIRC.
regards, tom lane
Bruce Momjian wrote: >Tom Lane wrote: > > >>Bruce Momjian <pgman@candle.pha.pa.us> writes: >> >> >>>Agreed, but from a clarity perspective, are we better moving to the CIDR >>>format for hostnames in pg_hba.conf anyway? >>> >>> >>Possibly --- it'd be easier to sell on that argument anyway ;-) >> >> >> s/hostnames/netmasks/ +1 vote. They are whole lot easier to understand anyway. We already did it for the IPv6 addr, and you thought it so nice you put it in the release notes :-) >>>Also, I think we would accept a patch that modified pg_hba.conf for >>>Solaris only that made this change. >>> >>> >>That seems like the worst of all possible worlds. Difficult to do *and* >>confusing for users, since on Solaris the sample file would no longer >>match the documentation. >> >> > >True, but at least it would work. Are they saying the masks don't work >at all? Why haven't we heard this before? > > > I thought the report was that *only* 255.255.255.255 failed. The question is why? And would changing the hints passed to getaddrinfo_all improve matters (e.g. by filling in the ai_family with the value from the addr structure we already have)? cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> I thought the report was that *only* 255.255.255.255 failed. The
> question is why?
The impression I got was that some internal subroutine of getaddrinfo
had a broken error-handling convention (ie, "return a numeric address
value or -1 on error").
> And would changing the hints passed to getaddrinfo_all
> improve matters (e.g. by filling in the ai_family with the value from
> the addr structure we already have)?
Seems unlikely. I suppose you could argue that we shouldn't be using
getaddrinfo on the netmask field at all; there's certainly not any value
in doing a DNS lookup on it, for instance. Maybe we should go back to
using plain ol' inet_aton for it? (Nah, won't handle IPv6...)
regards, tom lane
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > > I thought the report was that *only* 255.255.255.255 failed. The > > question is why? > > The impression I got was that some internal subroutine of getaddrinfo > had a broken error-handling convention (ie, "return a numeric address > value or -1 on error"). > > > And would changing the hints passed to getaddrinfo_all > > improve matters (e.g. by filling in the ai_family with the value from > > the addr structure we already have)? > > Seems unlikely. I suppose you could argue that we shouldn't be using > getaddrinfo on the netmask field at all; there's certainly not any value > in doing a DNS lookup on it, for instance. Maybe we should go back to > using plain ol' inet_aton for it? (Nah, won't handle IPv6...) Uh, we are passing 255.255.255.255 to getaddrinfo()? Why would we do that? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> writes: > > >>I thought the report was that *only* 255.255.255.255 failed. The >>question is why? >> >> > >The impression I got was that some internal subroutine of getaddrinfo >had a broken error-handling convention (ie, "return a numeric address >value or -1 on error"). > > Aha! Pardon me while I giggle. > > >>And would changing the hints passed to getaddrinfo_all >>improve matters (e.g. by filling in the ai_family with the value from >>the addr structure we already have)? >> >> > >Seems unlikely. I suppose you could argue that we shouldn't be using >getaddrinfo on the netmask field at all; there's certainly not any value >in doing a DNS lookup on it, for instance. Maybe we should go back to >using plain ol' inet_aton for it? (Nah, won't handle IPv6...) > > > > We could do it if we tested the addr.ai_family first, and only did it in the IPv4 case. I agree calling getaddrinfo is overkill for masks. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
>> Seems unlikely. I suppose you could argue that we shouldn't be using
>> getaddrinfo on the netmask field at all; there's certainly not any value
>> in doing a DNS lookup on it, for instance. Maybe we should go back to
>> using plain ol' inet_aton for it? (Nah, won't handle IPv6...)
> We could do it if we tested the addr.ai_family first, and only did it in
> the IPv4 case. I agree calling getaddrinfo is overkill for masks.
Huh? The reason we're using getaddrinfo in the first place is we don't
*know* whether we've got an IPv4 or IPv6 string ...
regards, tom lane
Bruce Momjian wrote: > > >Uh, we are passing 255.255.255.255 to getaddrinfo()? Why would we do that? > > Any non-CIDR netmask is passed to getaddrinfo to turn it into a binary mask. see src/backend/libpq/hba.c For CIDR masks we make the binary version ourselves. cheers andrew
Tom Lane wrote:
>Andrew Dunstan <andrew@dunslane.net> writes:
>
>
>>>Seems unlikely. I suppose you could argue that we shouldn't be using
>>>getaddrinfo on the netmask field at all; there's certainly not any value
>>>in doing a DNS lookup on it, for instance. Maybe we should go back to
>>>using plain ol' inet_aton for it? (Nah, won't handle IPv6...)
>>>
>>>
>
>
>
>>We could do it if we tested the addr.ai_family first, and only did it in
>>the IPv4 case. I agree calling getaddrinfo is overkill for masks.
>>
>>
>
>Huh? The reason we're using getaddrinfo in the first place is we don't
>*know* whether we've got an IPv4 or IPv6 string ...
>
>
>
>
We know the address family - in fact we pass it to SockAddr_cidr_mask().
It's only the family of the mask that we don't know. But they had better
be the same, of course. See hba.c around line 753:
if (cidr_slash) { if (SockAddr_cidr_mask(&mask, cidr_slash + 1,
addr.ss_family) < 0) goto hba_syntax; } else { /* Read the mask field. */
line_item = lnext(line_item); if (!line_item) goto hba_syntax; token =
lfirst(line_item);
ret = getaddrinfo_all(token, NULL, &hints, &gai_result);
cheers
andrew
Added to open items:
* Fix Solaris for single-host netmasks in pg_hba.conf, use CIDR?
---------------------------------------------------------------------------
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >Andrew Dunstan <andrew@dunslane.net> writes:
> >
> >
> >>>Seems unlikely. I suppose you could argue that we shouldn't be using
> >>>getaddrinfo on the netmask field at all; there's certainly not any value
> >>>in doing a DNS lookup on it, for instance. Maybe we should go back to
> >>>using plain ol' inet_aton for it? (Nah, won't handle IPv6...)
> >>>
> >>>
> >
> >
> >
> >>We could do it if we tested the addr.ai_family first, and only did it in
> >>the IPv4 case. I agree calling getaddrinfo is overkill for masks.
> >>
> >>
> >
> >Huh? The reason we're using getaddrinfo in the first place is we don't
> >*know* whether we've got an IPv4 or IPv6 string ...
> >
> >
> >
> >
>
> We know the address family - in fact we pass it to SockAddr_cidr_mask().
> It's only the family of the mask that we don't know. But they had better
> be the same, of course. See hba.c around line 753:
>
> if (cidr_slash)
> {
> if (SockAddr_cidr_mask(&mask, cidr_slash + 1,
> addr.ss_family) < 0)
> goto hba_syntax;
> }
> else
> {
> /* Read the mask field. */
> line_item = lnext(line_item);
> if (!line_item)
> goto hba_syntax;
> token = lfirst(line_item);
>
> ret = getaddrinfo_all(token, NULL, &hints, &gai_result);
>
> cheers
>
> andrew
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
Bruce Momjian wrote:
>Added to open items:
>
> * Fix Solaris for single-host netmasks in pg_hba.conf, use CIDR?
>
>
At this stage of the game I would just change pg_hba.conf.sample to use
'127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'. No need for a
Solaris-specific fix for the default setup if we do that, and I don't
have time right now to do what I suggested below.
cheers
andrew
>
>---------------------------------------------------------------------------
>
>Andrew Dunstan wrote:
>
>
>>Tom Lane wrote:
>>
>>
>>
>>>Andrew Dunstan <andrew@dunslane.net> writes:
>>>
>>>
>>>
>>>
>>>>>Seems unlikely. I suppose you could argue that we shouldn't be using
>>>>>getaddrinfo on the netmask field at all; there's certainly not any value
>>>>>in doing a DNS lookup on it, for instance. Maybe we should go back to
>>>>>using plain ol' inet_aton for it? (Nah, won't handle IPv6...)
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>>We could do it if we tested the addr.ai_family first, and only did it in
>>>>the IPv4 case. I agree calling getaddrinfo is overkill for masks.
>>>>
>>>>
>>>>
>>>>
>>>Huh? The reason we're using getaddrinfo in the first place is we don't
>>>*know* whether we've got an IPv4 or IPv6 string ...
>>>
>>>
>>>
>>>
>>>
>>>
>>We know the address family - in fact we pass it to SockAddr_cidr_mask().
>>It's only the family of the mask that we don't know. But they had better
>>be the same, of course. See hba.c around line 753:
>>
>> if (cidr_slash)
>> {
>> if (SockAddr_cidr_mask(&mask, cidr_slash + 1,
>>addr.ss_family) < 0)
>> goto hba_syntax;
>> }
>> else
>> {
>> /* Read the mask field. */
>> line_item = lnext(line_item);
>> if (!line_item)
>> goto hba_syntax;
>> token = lfirst(line_item);
>>
>> ret = getaddrinfo_all(token, NULL, &hints, &gai_result);
>>
>>cheers
>>
>>andrew
>>
>>
>>
>
>
>
Andrew Dunstan <andrew@dunslane.net> writes:
> At this stage of the game I would just change pg_hba.conf.sample to use
> '127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'.
Yeah, that's probably the path of least resistance. Note that the
comments and possibly the SGML docs need to be adjusted to match,
however, so it's not quite a one-liner.
regards, tom lane
Tom Lane wrote: >Andrew Dunstan <andrew@dunslane.net> writes: > > >>At this stage of the game I would just change pg_hba.conf.sample to use >>'127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'. >> >> > >Yeah, that's probably the path of least resistance. Note that the >comments and possibly the SGML docs need to be adjusted to match, >however, so it's not quite a one-liner. > > > > I think the SGML is fine. Here's a patch for the sample file. cheers andrew Index: src/backend/libpq/pg_hba.conf.sample =================================================================== RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/pg_hba.conf.sample,v retrieving revision 1.49 diff -c -r1.49 pg_hba.conf.sample *** src/backend/libpq/pg_hba.conf.sample 1 Aug 2004 05:58:35 -0000 1.49 --- src/backend/libpq/pg_hba.conf.sample 19 Aug 2004 17:30:56 -0000 *************** *** 35,40 **** --- 35,43 ---- # encrypted passwords. OPTION is the ident map or the name of the PAM # service. # + # Note: On some Solaris systems, an IP-MASK of 255.255.255.255 is known not to work. + # The corresponding CIDR-MASK of /32 does work. + # # Database and user names containing spaces, commas, quotes and other special # characters can be quoted. Quoting one of the keywords "all", "sameuser" or # "samegroup" makes the name lose its special character, and just match a *************** *** 49,56 **** # ---------------------------------- # # If you want to allow non-local connections, you need to add more ! # "host" records. Also, remember TCP/IP connections are only enabled ! # if you enable "tcpip_socket" in postgresql.conf. @authcomment@ --- 52,61 ---- # ---------------------------------- # # If you want to allow non-local connections, you need to add more ! # "host" records. In that case you will also need to make PostgreSQL listen ! # on a non-local interface via the listen_addresses configuration parameter, or ! # the -i or -h command line switches. ! # @authcomment@ *************** *** 58,63 **** local all all @authmethod@ # IPv4-style local connections: ! host all all 127.0.0.1 255.255.255.255 @authmethod@ # IPv6-style local connections: host all all ::1/128 @authmethod@ --- 63,68 ---- local all all @authmethod@ # IPv4-style local connections: ! host all all 127.0.0.1/32 @authmethod@ # IPv6-style local connections: host all all ::1/128 @authmethod@
Patch applied. Thanks. --------------------------------------------------------------------------- Andrew Dunstan wrote: > > > Tom Lane wrote: > > >Andrew Dunstan <andrew@dunslane.net> writes: > > > > > >>At this stage of the game I would just change pg_hba.conf.sample to use > >>'127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'. > >> > >> > > > >Yeah, that's probably the path of least resistance. Note that the > >comments and possibly the SGML docs need to be adjusted to match, > >however, so it's not quite a one-liner. > > > > > > > > > > I think the SGML is fine. Here's a patch for the sample file. > > cheers > > andrew > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073