Proposal: allow non-masked IPs inside of pg_hba.conf - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Proposal: allow non-masked IPs inside of pg_hba.conf
Date
Msg-id CAKAnmmLUQpbkLDN-P142sx8QcqwKZOsQfE+bUf3WmEF9b-gf6Q@mail.gmail.com
Whole thread Raw
Responses Re: Proposal: allow non-masked IPs inside of pg_hba.conf
List pgsql-hackers
Currently, all IP addresses in the address field of records in the pg_hba.conf file require a CIDR mask. This means that rather than the intuitive way to add a single IP address:

host postgres alice 10.128.0.10  scram-sha-256

One must do:

host postgres alice 10.128.0.10/32  scram-sha-256

I'd like to relax that requirement, such that a lack of an explicit mask defaults to a /32 mask, allowing that first example to work as most people would expect. Many Postgres users are not aware of why a /32 is needed (and what it means), and simply copy and paste. Worse, they sometimes paste the wrong mask. An issue I've seen is to say /0 when they mean a /32 (which is really bad from a security perspective - see nearby thread for a patch to prevent that).

Another problem with the mask requirement is that currently a failure to add a mask means we scan the method as the mask (!), and give a very unhelpful error message like this:

LOG:  invalid IP mask "scram-sha-256": Name or service not known

Having a default of /32 is very common among many other programs and systems (e.g. ssh, iptables, cftable, nginx, haproxy, docker). While there are a few ancient networking programs that default to /24, they are the exception, and this change will fail in a secure direction.

This should have no backwards compatibility issues, as we do not currently allow non-masks, and we are defaulting to the strictest mask. Of course, ipv6 will default to /128

Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
  

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
Next
From: Melanie Plageman
Date:
Subject: Re: pgbench with partitioned tables