Re: CIDR in pg_hba.conf - Mailing list pgsql-hackers

Amazing the amount of mail a tiny thing like this generates ;-)

Here's what I intend to do:

. for now, just CIDR, no DNS names, which can easily be added later (like
next week)
. The syntax will be either the current syntax (address space
old-style-mask) or standard CIDR notation (address slash maskbits).
. The constructed mask for CIDR will have the same family (AF_INET or
AF_INET6) as the address, but will otherwise be independent of it (unlike
squid, apparently - see below).

I have a couple of questions about portability etc., that some folks here
might be able to answer:
. can I rely on the availability of htonl() ?
. am I correct in assuming that the the leftmost parts of
in6.sin6_addr.s6_addr are the network portion of the address?

If the answer is yes to both, I'm just about finished coding this. I don't
have an IPv6 environment for testing, though.

The mask constructor is a new function in ip.c with this signature:

int
SockAddr_cidr_mask(SockAddr *mask, char *numbits, int family)

I can easily call it something else, though :-)

Regarding DNS names:
. I can't see any reason not to allow netmasks for named addresses, in
either the old form or CIDR.
. Using *any* form of host based auth on the Internet is dangerous - DNS
just adds one more element of danger to the mix, and I am uninclined to do
handstands trying to mitigate the risk for people who should probably be
using SSL and other strong auth.
. the major advantage I see would be within an enterprise, especially where
DHCP is used, to restrict the db to certain workstations.

cheers

andrew


----- Original Message ----- 
From: "Matthew Kirkwood" <matthew@hairy.beasts.org>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Larry Rosenman" <ler@lerctr.org>; "Andrew Dunstan"
<andrew@dunslane.net>; "PostgreSQL Hackers Mailing List"
<pgsql-hackers@postgresql.org>
Sent: Wednesday, May 07, 2003 4:19 PM
Subject: Re: [HACKERS] CIDR in pg_hba.conf


> 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.