Thread: Proposal: allow non-masked IPs inside of pg_hba.conf
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
Greg Sabino Mullane <htamfids@gmail.com> writes:
> Currently, all IP addresses in the address field of records in the
> pg_hba.conf file require a CIDR mask.
> ...
> 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.
This too would work better if hba.c were sharing cidr_in's logic:
regression=# select '1.2.3.4'::cidr;
cidr
------------
1.2.3.4/32
(1 row)
regards, tom lane
This too would work better if hba.c were sharing cidr_in's logic:
+1, a two-for-one solution.
Cheers,
Greg