From: Tom Lane <tgl@sss.pgh.pa.us>
To: petervandivier@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16695: pg_hba_file_rules NULL address and netmask
In-reply-to: <16695-a665558e2f630be7@postgresql.org>
References: <16695-a665558e2f630be7@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 02 Nov 2020 21:01:00 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <832502.1604361320.1@sss.pgh.pa.us>
Date: Mon, 02 Nov 2020 18:55:20 -0500
Message-ID: <832503.1604361320@sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.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