PATCH: Disallow a netmask of zero unless the IP is also all zeroes
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t51049psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 03:54 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t51049_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t51049_1 && git checkout t51049_1Patchset v1 (message #1) is on t51049_1
I ran into this alarming mistake again the other day. Luckily it was on a
dev system. Someone sees an entry in a pg_hba.conf that looks like this:
host all all 0.0.0.0/0 md5
They are gobsmacked when they learn this means to let everyone in. So they
fix it by adding new entries that look like this:
host all all 10.2.55.4/0 md5
host all all 10.2.55.5/0 md5
host all all 10.2.55.6/0 md5
It should, of course, be:
host all all 10.2.55.4/32 md5
I say "of course" but few people (even tech ones) know the distinction.
(Nor should they have to! But that's for a nearby thread). This patch aims
to prevent this very bad footgun by only allowing a /0 if the IP consists
of only zeroes. It works for ipv4 and ipv6.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
Greg Sabino Mullane <htamfids@gmail.com> writes:
I say "of course" but few people (even tech ones) know the distinction.
(Nor should they have to! But that's for a nearby thread). This patch aims
to prevent this very bad footgun by only allowing a /0 if the IP consists
of only zeroes. It works for ipv4 and ipv6.
More generally, should we reject if the netmask causes *any* nonzero
IP bits to be ignored? Our CIDR type already imposes that rule:
regression=# select '1.2.3.4/24'::cidr;
ERROR: invalid cidr value: "1.2.3.4/24"
LINE 1: select '1.2.3.4/24'::cidr;
^
DETAIL: Value has bits set to right of mask.
I'm a bit distressed to realize that hba.c isn't using cidr_in.
Maybe we should try to share code instead of duplicating yet more.
regards, tom lane
On 11 Feb 2025, at 21:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'm a bit distressed to realize that hba.c isn't using cidr_in.
Maybe we should try to share code instead of duplicating yet more.
+1. I have a note along these lines on my never-shrinking TODO, I think it
would be great if we took a stab at that.
--
Daniel Gustafsson
On Tue, Feb 11, 2025 at 3:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
More generally, should we reject if the netmask causes *any* nonzero
IP bits to be ignored? Our CIDR type already imposes that rule:
Yeah, I like that idea a lot. That's a great DETAIL message.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
On 2/11/25 9:25 PM, Tom Lane wrote:
Greg Sabino Mullane <htamfids@gmail.com> writes:
I say "of course" but few people (even tech ones) know the distinction.
(Nor should they have to! But that's for a nearby thread). This patch aims
to prevent this very bad footgun by only allowing a /0 if the IP consists
of only zeroes. It works for ipv4 and ipv6.More generally, should we reject if the netmask causes *any* nonzero
IP bits to be ignored? Our CIDR type already imposes that rule:
+1 From me too. I think we should fix the general issue rather than
special casing /0.
Andreas