Re: BUG #16695: pg_hba_file_rules NULL address and netmask

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: petervandivier(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16695: pg_hba_file_rules NULL address and netmask
Date: 2020-11-02 23:55:20
Message-ID: 832503.1604361320@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> pg_hba_file_rules reports NULL address and netmask values incorrectly on
> FreeBSD 11 for tested postgres versions 10-13 (at least). e.g.

So for the archives' sake: what I suppose Peter means is that the addr
and netmask come out as NULL on every line, even where they should not.
At least, that's what I've reproduced here on FreeBSD 11.0.

I traced through this, and the proximate cause seems to be that
getnameinfo(3) is failing because it is expecting the passed "salen"
to be exactly the length it is expecting for the given sa_family.

Which it is not, because alone among our callers of pg_getnameinfo_all(),
fill_hba_line() thinks it can get away with passing sizeof(struct
sockaddr_storage) rather than the actual addrlen previously returned by
getaddrinfo().

The POSIX specification for getnameinfo() saith

The sa argument points to a socket address structure to be
translated. The salen argument contains the length of the address
pointed to by sa.

so it seems to me that fill_hba_line() is clearly in the wrong. There
are evidently a lot of implementations that either don't check salen
or only insist it be >= required length, but POSIX doesn't say they
need to be that lax. (It'd be interesting to know if anyone sees
similar failures on any other BSDen.)

The core of the problem is somebody being lazy about what they needed
to put into HbaLine. Unfortunately that's an exported structure so
there's some small risk of an ABI break, but I guess we can add the
length fields at the end in released branches to minimize the hazard.

Thanks for the report!

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2020-11-03 00:00:37 Re: BUG #16696: Backend crash in llvmjit
Previous Message Tom Lane 2020-11-02 22:50:08 Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch