On Wed, 7 May 2003, Tom Lane wrote:
> >> So in hba.c, if we found a / in the IP address, we wouldn't go looking
> >> for a separate netmask field.
> It works for me. One thought though: someday someone might want to
> get around to allowing a DNS name in the host field, too. Can we
> define a test that handles all three cases? Perhaps do this:
>
> * If IP address contains only 0-9 and dot (easily coded with
> strspn()), then it's old-style IP address; expect netmask as next
> field.
>
> * If IP address contains only 0-9, dot, and slash, then it's CIDR;
> there's no separate netmask field.
If you're going to do this, please allow both 1.2.3.4/24
and 1.2.3.4/255.255.255.0 styles. For both (see example)
please don't follow the staggeringly brain-dead squid
insistence the no bits may be set in the address which are
cleared by the mask. Similarly, please don't insist that
> * Otherwise IP address is a DNS name; there's no separate netmask.
> (This case can error out for now, unless you're feeling ambitious.)
Why should hostnames not allow netmasks? I find it very
useful for similar things to have a lot of names in
/etc/hosts so I can do things like "dmz-net/24" or even
"router/24".
I have a couple of packages which need to do similar things
and I see no reason to disallow any such thing. At:
http://hairy.beasts.org/fk/fk/acl/acl.c:new_acl_host()
is a short routine which parses IP ranges with IP or DNS
name, and with or without netmask in either format. Note
that it's careful to do any name lookups lazily (and that
it only does forward lookups -- that's important).
That file is GPLed, but I'm happy for use of this routine
under the postgres licence. Actually, I'm quite pleased
with the ACL facility there -- it might be a fun project
to investigate tacking something like that onto postgres
instead of the pg_hba.conf mechanisms:
http://hairy.beasts.org/fk/fk/doc/README.acl
There's a slightly more readable description of a similar
thing at:
http://hairy.beasts.org/filter/filtergen/README
though that package does static translation.
Matthew.