CIDR in pg_hba.conf

--On Wednesday, May 07, 2003 09:50:55 -0400 Andrew Dunstan
<andrew@dunslane.net> wrote:

Looking through the TODO list I noticed this item apparently unclaimed:

* Allow CIDR format to be used in pg_hba.conf

I can look at doing this, having done similar code some years ago.

Internally, it seems the best thing to do would be to turn the /nn into a
conventional netmask of the right family. I guess I'd add a utility
routine to ip.c for that.

The syntax for pg_hba.conf would change slightly, to allow these forms:

host database user CIDR-address authentication-method
[authentication-option]
hostssl database user CIDR-address authentication-method
[authentication-option]

So in hba.c, if we found a / in the IP address, we wouldn't go looking
for a separate netmask field.

Please do this !

LER

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Larry Rosenman <ler@lerctr.org> writes:

--On Wednesday, May 07, 2003 09:50:55 -0400 Andrew Dunstan

So in hba.c, if we found a / in the IP address, we wouldn't go looking
for a separate netmask field.

Please do this !

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.

* Otherwise IP address is a DNS name; there's no separate netmask.
(This case can error out for now, unless you're feeling ambitious.)

regards, tom lane

On Wednesday 07 May 2003 09:50, Andrew Dunstan wrote:

So in hba.c, if we found a / in the IP address, we wouldn't go looking for
a separate netmask field.

Is anyone else uncomfortable with variable number of fields? I know there is
prior art but it still spooks me a little. How about a space after the
address and before the slash? That way the netmask is in the same field as
always (as are the following fields) and it's just an alternative syntax.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On Wed, 7 May 2003, D'Arcy J.M. Cain wrote:

On Wednesday 07 May 2003 09:50, Andrew Dunstan wrote:

So in hba.c, if we found a / in the IP address, we wouldn't go looking for
a separate netmask field.

Is anyone else uncomfortable with variable number of fields? I know there is
prior art but it still spooks me a little. How about a space after the
address and before the slash? That way the netmask is in the same field as
always (as are the following fields) and it's just an alternative syntax.

If that's the case, then just drop the / from the address and make the
mask field varialble, so if it has .s in it it's a netmask, otherwise it's
a number like a CIDR's second half.

I'm feeling ambitious ;-)

Seriously, I think this would be very worthwhile - I hate having to remember
IP addresses.

It would all be done by now except that I have to handle the IPv6 stuff
(thanks god for edition 2 of Stevens).

andrew

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

I would far rather have standard CIDR notation - inventing a new one for Pg
doesn't make sense to me.

I do not at all understand the objection to a variable number of fields. In
fact, we already have them (there's an optional authentication_option on the
end).

If you don't like this scheme, you can avoid use of CIDR notation (or
hostnames) and the pg_hba.conf will work exactly as before.

andrew

----- Original Message -----
From: "scott.marlowe" <scott.marlowe@ihs.com>
To: "D'Arcy J.M. Cain" <darcy@druid.net>
Cc: "Andrew Dunstan" <andrew@dunslane.net>; "PostgreSQL Hackers Mailing
List" <pgsql-hackers@postgresql.org>
Sent: Wednesday, May 07, 2003 1:44 PM
Subject: Re: [HACKERS] CIDR in pg_hba.conf

On Wed, 7 May 2003, D'Arcy J.M. Cain wrote:

On Wednesday 07 May 2003 09:50, Andrew Dunstan wrote:

So in hba.c, if we found a / in the IP address, we wouldn't go looking

for

a separate netmask field.

Is anyone else uncomfortable with variable number of fields? I know

there is

prior art but it still spooks me a little. How about a space after the
address and before the slash? That way the netmask is in the same field

as

always (as are the following fields) and it's just an alternative

syntax.

--On Wednesday, May 07, 2003 11:44:12 -0600 "scott.marlowe"
<scott.marlowe@ihs.com> wrote:

On Wed, 7 May 2003, D'Arcy J.M. Cain wrote:

On Wednesday 07 May 2003 09:50, Andrew Dunstan wrote:

So in hba.c, if we found a / in the IP address, we wouldn't go looking
for a separate netmask field.

Is anyone else uncomfortable with variable number of fields? I know
there is prior art but it still spooks me a little. How about a space
after the address and before the slash? That way the netmask is in the
same field as always (as are the following fields) and it's just an
alternative syntax.

If that's the case, then just drop the / from the address and make the
mask field varialble, so if it has .s in it it's a netmask, otherwise
it's a number like a CIDR's second half.

I'd prefer to have the /'s. It makes it easier to generate the file
magically (perhaps from PG itself).

LER

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

I agree with this

-*- Andrew Dunstan <andrew@dunslane.net> [ 2003-05-07 18:27 ]:

I would far rather have standard CIDR notation - inventing a new one for Pg
doesn't make sense to me.

I do not at all understand the objection to a variable number of fields. In
fact, we already have them (there's an optional authentication_option on the
end).

If you don't like this scheme, you can avoid use of CIDR notation (or
hostnames) and the pg_hba.conf will work exactly as before.

andrew

----- Original Message -----
From: "scott.marlowe" <scott.marlowe@ihs.com>
To: "D'Arcy J.M. Cain" <darcy@druid.net>
Cc: "Andrew Dunstan" <andrew@dunslane.net>; "PostgreSQL Hackers Mailing
List" <pgsql-hackers@postgresql.org>
Sent: Wednesday, May 07, 2003 1:44 PM
Subject: Re: [HACKERS] CIDR in pg_hba.conf

On Wed, 7 May 2003, D'Arcy J.M. Cain wrote:

On Wednesday 07 May 2003 09:50, Andrew Dunstan wrote:

So in hba.c, if we found a / in the IP address, we wouldn't go looking

for

a separate netmask field.

Is anyone else uncomfortable with variable number of fields? I know

there is

prior art but it still spooks me a little. How about a space after the
address and before the slash? That way the netmask is in the same field

as

always (as are the following fields) and it's just an alternative

syntax.

If that's the case, then just drop the / from the address and make the
mask field varialble, so if it has .s in it it's a netmask, otherwise it's
a number like a CIDR's second half.

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

--
Kveðja,
Tolli
tolli@tol.li

--On Wednesday, May 07, 2003 13:57:21 -0400 Andrew Dunstan
<andrew@dunslane.net> wrote:

I'm feeling ambitious ;-)

Seriously, I think this would be very worthwhile - I hate having to
remember IP addresses.

It would all be done by now except that I have to handle the IPv6 stuff
(thanks god for edition 2 of Stevens).

andrew

One thing I thought of, is when do you do the resolution of name-to-ip?
You may need
to think about spoofs and DNS issues.

Please think about this, as cache-poisoning, and trashy reverse-DNS is a
real issue
out there.

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

I too favor variable numbers of fields. My only point was that if it was
gonna be done as two fields to leave out the / as it is noise at that
point.

On Wed, 7 May 2003, Andrew Dunstan wrote:

My slightly cursory look at the relevant section of hba.c suggests that the
resolution would done at connect time, not at file parse time - I'm sure
someone will correct me if I'm wrong.

I wasn't going to do reverse lookup - do you think we should? Basically I
was going to match if a forward mapping of the DNS name matched the socket
address.

The other issue is that doing an address lookup has the potential to add
hugely to the time taken to establish connections - CNAMEs will make this
worse, caching will make it better. Using reverse lookups would
significantly increase this impact.

Maybe we need to think a bit harder about this. Or at the very least put a
prominent warning in the docs and sample files, just like Apache does in
relation to the same issue for log files etc.

andrew

----- Original Message -----
From: "Larry Rosenman" <ler@lerctr.org>

--On Wednesday, May 07, 2003 15:12:42 -0400 Andrew Dunstan
<andrew@dunslane.net> wrote:

My slightly cursory look at the relevant section of hba.c suggests that
the resolution would done at connect time, not at file parse time - I'm
sure someone will correct me if I'm wrong.

I think it needs to be done at file parse time, and double-reverse tested.

And re-parse on SIGHUP.

I wasn't going to do reverse lookup - do you think we should? Basically I
was going to match if a forward mapping of the DNS name matched the socket
address.

It can be spoofed then. You would need to double-reverse check it.

The other issue is that doing an address lookup has the potential to add
hugely to the time taken to establish connections - CNAMEs will make this
worse, caching will make it better. Using reverse lookups would
significantly increase this impact.

Another reason to do it at FILE PARSE time, so that we don't do it as
often.

Maybe we need to think a bit harder about this. Or at the very least put a
prominent warning in the docs and sample files, just like Apache does in
relation to the same issue for log files etc.

Being in the ISP biz, and also running DNS for folks, I figured I'd raise
the issue.

I was thinking file parse time, so you could turn the records into /32's in
the parsed
representation. Also, what about **MULTIPLE** A records for the same name?

LER

andrew

----- Original Message -----
From: "Larry Rosenman" <ler@lerctr.org>

One thing I thought of, is when do you do the resolution of name-to-ip?
You may need
to think about spoofs and DNS issues.

Please think about this, as cache-poisoning, and trashy reverse-DNS is a
real issue
out there.

LER

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

On Wednesday 07 May 2003 14:05, Andrew Dunstan wrote:

I do not at all understand the objection to a variable number of fields. In
fact, we already have them (there's an optional authentication_option on
the end).

It is a mild objection and I realize that it has been done before (owner:group
field in newsyslog.conf was the one I was thinking of) but what is being
proposed is not the same as having optional trailing fields like we have now.
With or without the auth option, every other field is in the same position.
This change would modify the positions of the following fields. That's the
part that spooks me.

But, as I said, it is a mild objection and I prefer having the CIDR notation
more than I object to the variable number of fields.

Tom mentioned the idea of rolling in names as well. Good idea but he
suggested that in that case the mask would always be left out (assumed to be
/32) but I am not so sure. You can have networks in your DNS and so netmasks
make sense for names too.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On Wednesday 07 May 2003 13:44, scott.marlowe wrote:

On Wed, 7 May 2003, D'Arcy J.M. Cain wrote:

Is anyone else uncomfortable with variable number of fields? I know
there is prior art but it still spooks me a little. How about a space
after the address and before the slash? That way the netmask is in the
same field as always (as are the following fields) and it's just an
alternative syntax.

If that's the case, then just drop the / from the address and make the
mask field varialble, so if it has .s in it it's a netmask, otherwise it's
a number like a CIDR's second half.

That works for me too.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On Wed, May 07, 2003 at 15:12:42 -0400,
Andrew Dunstan <andrew@dunslane.net> wrote:

My slightly cursory look at the relevant section of hba.c suggests that the
resolution would done at connect time, not at file parse time - I'm sure
someone will correct me if I'm wrong.

I wasn't going to do reverse lookup - do you think we should? Basically I
was going to match if a forward mapping of the DNS name matched the socket
address.

There isn't a reason to do reverse lookups in this case. It will just
make things harder to use (in the case where there are multiple A
records pointing to the same IP address) and won't add any useful
security.

The other issue is that doing an address lookup has the potential to add
hugely to the time taken to establish connections - CNAMEs will make this
worse, caching will make it better. Using reverse lookups would
significantly increase this impact.

Once your local DNS cache has the A records cached the slowdown should
be minimal.

Maybe we need to think a bit harder about this. Or at the very least put a
prominent warning in the docs and sample files, just like Apache does in
relation to the same issue for log files etc.

Yes there should be something about possible delays in the docs as well
as mentioning that the domain to IP address translation happens at
connect time, not server start up.

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.

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

--On Wednesday, May 07, 2003 15:07:15 -0500 Bruno Wolff III
<bruno@wolff.to> wrote:

On Wed, May 07, 2003 at 15:12:42 -0400,
Andrew Dunstan <andrew@dunslane.net> wrote:

My slightly cursory look at the relevant section of hba.c suggests that
the resolution would done at connect time, not at file parse time - I'm
sure someone will correct me if I'm wrong.

I wasn't going to do reverse lookup - do you think we should? Basically I
was going to match if a forward mapping of the DNS name matched the
socket address.

There isn't a reason to do reverse lookups in this case. It will just
make things harder to use (in the case where there are multiple A
records pointing to the same IP address) and won't add any useful
security.

probably true, but, might still make things hard. I would still prefer to
see
a paranoid lookup: name->ip->name and make sure it's sane.
(My abuse/security/paranoid hat).

The other issue is that doing an address lookup has the potential to add
hugely to the time taken to establish connections - CNAMEs will make this
worse, caching will make it better. Using reverse lookups would
significantly increase this impact.

Once your local DNS cache has the A records cached the slowdown should
be minimal.

Maybe we need to think a bit harder about this. Or at the very least put
a prominent warning in the docs and sample files, just like Apache does
in relation to the same issue for log files etc.

Yes there should be something about possible delays in the docs as well
as mentioning that the domain to IP address translation happens at
connect time, not server start up.

see my other comment on why I think it might make sense to do the lookup(s)
at
Parse Time.

LER

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

--On Wednesday, May 07, 2003 17:06:18 -0400 Andrew Dunstan
<andrew@dunslane.net> wrote:

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

you just hit some nerves, and stuff. :-)

Here's what I intend to do:

. for now, just CIDR, no DNS names, which can easily be added later (like
next week)

Makes sense to me :-).

. The syntax will be either the current syntax (address space
old-style-mask) or standard CIDR notation (address slash maskbits).

Thank You.

. 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() ?

I believe so.

. am I correct in assuming that the the leftmost parts of
in6.sin6_addr.s6_addr are the network portion of the address?

I believe so, there is an IPv6 API on UnixWare, http://www.lerctr.org:8458/
is my
server's Docs.

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.

debatable, but, I'll not complain about it, just I won't use it :-) .

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

Ok, but I wanted the issues out in the open.

. the major advantage I see would be within an enterprise, especially
where DHCP is used, to restrict the db to certain workstations.

How does DNS help here? Most times the DHCP pool has pool like DNS Names.

(At least in my type thereof).

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.

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749