Thread: CIDR in pg_hba.conf
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. cheers andrew
--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 > 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 > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster
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.
--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: > 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 >
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> > 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 >
--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 > > >> 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.
--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
On Wed, May 07, 2003 at 09:50:55AM -0400, Andrew Dunstan wrote: > Looking through the TODO list I noticed this item apparently unclaimed: > > * Allow CIDR format to be used in pg_hba.conf I mailed an ipv6 patch a few days ago that included CIDR in pg_hba.conf. I first tried mailing it here, then to -patches, and finaly send it to Tom Lane and I hope he received it. Kurt
Kurt Roeckx <Q@ping.be> writes:
> I mailed an ipv6 patch a few days ago that included CIDR in
> pg_hba.conf.
> I first tried mailing it here, then to -patches, and finaly send
> it to Tom Lane and I hope he received it.
I did get it, but haven't looked at it --- I have a few other things
on my plate at the moment ...
I would imagine that your other submissions got stuck in the moderator's
queue (Marc has a few things on his plate too :-(). Are you sure you
are subscribed to -patches? Under the same address you mailed from?
regards, tom lane
On Wed, May 07, 2003 at 11:53:51PM -0400, Tom Lane wrote: > I would imagine that your other submissions got stuck in the moderator's > queue (Marc has a few things on his plate too :-(). Are you sure you > are subscribed to -patches? Under the same address you mailed from? I'm not, and I didn't intend to subscribe either just to send 1 patch. Kurt
You can send it to -patches and the moderator will allow it to go thru - you don't have to subscribe. Chris ----- Original Message ----- From: "Kurt Roeckx" <Q@ping.be> To: "Tom Lane" <tgl@sss.pgh.pa.us> Cc: "Andrew Dunstan" <andrew@dunslane.net>; "PostgreSQL Hackers Mailing List" <pgsql-hackers@postgresql.org> Sent: Thursday, May 08, 2003 2:11 PM Subject: Re: [HACKERS] CIDR in pg_hba.conf > On Wed, May 07, 2003 at 11:53:51PM -0400, Tom Lane wrote: > > I would imagine that your other submissions got stuck in the moderator's > > queue (Marc has a few things on his plate too :-(). Are you sure you > > are subscribed to -patches? Under the same address you mailed from? > > I'm not, and I didn't intend to subscribe either just to send 1 > patch. > > > Kurt > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org >
On Wed, May 07, 2003 at 16:11:01 -0500, Larry Rosenman <ler@lerctr.org> wrote: > > a paranoid lookup: name->ip->name and make sure it's sane. > (My abuse/security/paranoid hat). You don't have to do paranoid lookups when starting with a forward address. You need to do paranoid lookups when starting with a reverse address. The reason to start with a reverse address is it may be too costly to just try forward addresses until you get a match. However this might be relevant to hba.conf. If there are lots of forward addresses in the file and the plan is to check them at connection time instead of server start time, then it may be a good idea to do a reverse lookup for efficiency. If you do start with a reverse lookup this will cause problems for people that don't control their reverse DNS and to some extent for machines that have several A records pointing to their IP address, since you really should only have one PTR record (since there is software that assumes there is only one) and you will need to be careful to use the matching A record in hba.conf.
seems like before andrew dunstan's patch could be applied someone needs to look at kurt's. rather than waiting for marc perhaps tom can forward the patch to -patches? Robert Treat On Thu, 2003-05-08 at 02:45, Christopher Kings-Lynne wrote: > You can send it to -patches and the moderator will allow it to go thru - you > don't have to subscribe. > > Chris > > ----- Original Message ----- > From: "Kurt Roeckx" <Q@ping.be> > To: "Tom Lane" <tgl@sss.pgh.pa.us> > Cc: "Andrew Dunstan" <andrew@dunslane.net>; "PostgreSQL Hackers Mailing > List" <pgsql-hackers@postgresql.org> > Sent: Thursday, May 08, 2003 2:11 PM > Subject: Re: [HACKERS] CIDR in pg_hba.conf > > > > On Wed, May 07, 2003 at 11:53:51PM -0400, Tom Lane wrote: > > > I would imagine that your other submissions got stuck in the moderator's > > > queue (Marc has a few things on his plate too :-(). Are you sure you > > > are subscribed to -patches? Under the same address you mailed from? > > > > I'm not, and I didn't intend to subscribe either just to send 1 > > patch. > > > > > > Kurt > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 6: Have you searched our list archives? > > > > http://archives.postgresql.org > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Kurt Roeckx <Q@ping.be> writes:
> On Wed, May 07, 2003 at 11:53:51PM -0400, Tom Lane wrote:
>> I would imagine that your other submissions got stuck in the moderator's
>> queue (Marc has a few things on his plate too :-(). Are you sure you
>> are subscribed to -patches? Under the same address you mailed from?
> I'm not, and I didn't intend to subscribe either just to send 1
> patch.
Fair enough, but then you'll have to be patient till Marc goes through
the moderator's approval queue. I'm not sure if he's back from
emergency server repairs in Panama yet, but in any case I haven't
noticed him doing the queue for several days ...
(You should have gotten an autoreply telling you the message was held
for moderator approval, btw. I always get one when I post to a PG list
I'm not subscribed to.)
regards, tom lane
On Wed, May 07, 2003 at 04:11:01PM -0500, Larry Rosenman wrote: > a paranoid lookup: name->ip->name and make sure it's sane. > (My abuse/security/paranoid hat). If you're being paranoid, why use hostnames at all? A -- ---- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M2P 2A8 +1 416 646 3304 x110
--On Thursday, May 08, 2003 11:00:18 -0400 Andrew Sullivan <andrew@libertyrms.info> wrote: > On Wed, May 07, 2003 at 04:11:01PM -0500, Larry Rosenman wrote: >> a paranoid lookup: name->ip->name and make sure it's sane. >> (My abuse/security/paranoid hat). > > If you're being paranoid, why use hostnames at all? My point. But, if we are going to allow hostnames, we ought to make sure the userbase (and us) understand the holes. 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
Yeah, I'm going to stop for now. Kurt sent me a copy of his patch - it's quite large (2329 lines of diff) while mine is small (~120 lines of diff) and would conflict with what he has done. If his patch doesn't appear on patches soon I'll post it there, along with my patch, so people can look at them and decide what is wanted. andrew ----- Original Message ----- From: "Robert Treat" <xzilla@users.sourceforge.net> To: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> Cc: "Kurt Roeckx" <Q@ping.be>; "Tom Lane" <tgl@sss.pgh.pa.us>; "Andrew Dunstan" <andrew@dunslane.net>; "PostgreSQL Hackers Mailing List" <pgsql-hackers@postgresql.org> Sent: Thursday, May 08, 2003 9:34 AM Subject: Re: [HACKERS] CIDR in pg_hba.conf > seems like before andrew dunstan's patch could be applied someone needs > to look at kurt's. rather than waiting for marc perhaps tom can forward > the patch to -patches? > > Robert Treat > > On Thu, 2003-05-08 at 02:45, Christopher Kings-Lynne wrote: > > You can send it to -patches and the moderator will allow it to go thru - you > > don't have to subscribe. > > > > Chris > > > > ----- Original Message ----- > > From: "Kurt Roeckx" <Q@ping.be> > > To: "Tom Lane" <tgl@sss.pgh.pa.us> > > Cc: "Andrew Dunstan" <andrew@dunslane.net>; "PostgreSQL Hackers Mailing > > List" <pgsql-hackers@postgresql.org> > > Sent: Thursday, May 08, 2003 2:11 PM > > Subject: Re: [HACKERS] CIDR in pg_hba.conf > > > > > > > On Wed, May 07, 2003 at 11:53:51PM -0400, Tom Lane wrote: > > > > I would imagine that your other submissions got stuck in the moderator's > > > > queue (Marc has a few things on his plate too :-(). Are you sure you > > > > are subscribed to -patches? Under the same address you mailed from? > > > > > > I'm not, and I didn't intend to subscribe either just to send 1 > > > patch. > > > > > > > > > Kurt > > >
On Thu, 8 May 2003, Larry Rosenman wrote: > >> a paranoid lookup: name->ip->name and make sure it's sane. > >> (My abuse/security/paranoid hat). > > > > If you're being paranoid, why use hostnames at all? > > My point. But, if we are going to allow hostnames, we ought to make > sure the userbase (and us) understand the holes. But _there are none_ if you only do forward lookups. Matthew.
On Thu, May 08, 2003 at 11:01:16PM +0100, Matthew Kirkwood wrote: > On Thu, 8 May 2003, Larry Rosenman wrote: > > > >> a paranoid lookup: name->ip->name and make sure it's sane. > > >> (My abuse/security/paranoid hat). > > > > > > If you're being paranoid, why use hostnames at all? > > > > My point. But, if we are going to allow hostnames, we ought to make > > sure the userbase (and us) understand the holes. > > But _there are none_ if you only do forward lookups. There are. You can even make an authoritative nameserver return a wrong answer. It can only make sense if you only look it up once on start up (or rehash), but then what is the point of it? And even that is questionable. You should NEVER do authentication based on a hostname. You can't even always rely on an IP address (or MAC address). Kurt
On Fri, May 09, 2003 at 00:59:58 +0200, Kurt Roeckx <Q@ping.be> wrote: > > There are. You can even make an authoritative nameserver return > a wrong answer. This is incorrect. You might be able to DNS spoofing to fake a response, but in that case a reverse lookup isn't going to help. Because in theory the person in control of what a domain name means is also (indirectly) in control of the DNS records for that name it is reasonable to trust DNS for forward resolution of domain names. Reverse lookups are different. In theory whoever is in control of the IP address for which a PTR record is being looked up controls what is returned. Since this isn't necessarily whoever controls the domain returned, you need to do a forward lookup to check and make sure the IP address is listed. > It can only make sense if you only look it up once on start up > (or rehash), but then what is the point of it? And even that is > questionable. Efficiency. If there are a number of domain name entries you may only want to check them when reading hba.conf. This does break some useful things about using domain names in hba.conf. > You should NEVER do authentication based on a hostname. You > can't even always rely on an IP address (or MAC address). NEVER is too strong. Certainly there is additional risk in doing this, but depending on the benefits of doing this it may be a useful tradeoff.
On Thu, 8 May 2003, Bruno Wolff III wrote: > On Fri, May 09, 2003 at 00:59:58 +0200, > Kurt Roeckx <Q@ping.be> wrote: > > > > There are. You can even make an authoritative nameserver return > > a wrong answer. > > This is incorrect. Actually, you can quite easily make an authoratative nameserver return an incorrect answer through cache poisoning, if the particular software and version happens to have that bug and recursive searches are turned on. However, it's also possible to set up nameservers securely, so you shouldn't use this an an excuse never to use hostnames. > Efficiency. If there are a number of domain name entries you may only > want to check them when reading hba.conf. This does break some useful > things about using domain names in hba.conf. Personally, I think the best way to deal with the issue is, if the connecting IP address is not found in hba.conf, do an in-addr.arpa lookup on the IP address and see if you get a hostname. If you do, check the hba.conf for that hostname. If the hba.conf has the hostname, then you do a forward lookup on it and make sure that there's an A record matching that IP address. Yes, it can slow things down significantly. But you can still always just hardwire the IP addresses in hba.conf if you want to avoid the slowdown and the addresses don't change often. However, if the addresses do change often, this gives you the option of having the server follow the changes automatically, at the price of a slowdown in connecting. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
On Fri, May 09, 2003 at 13:40:18 +0900, Curt Sampson <cjs@cynic.net> wrote: > On Thu, 8 May 2003, Bruno Wolff III wrote: > > > On Fri, May 09, 2003 at 00:59:58 +0200, > > Kurt Roeckx <Q@ping.be> wrote: > > > > > > There are. You can even make an authoritative nameserver return > > > a wrong answer. > > > > This is incorrect. > > Actually, you can quite easily make an authoratative nameserver return > an incorrect answer through cache poisoning, if the particular software > and version happens to have that bug and recursive searches are turned on. > > However, it's also possible to set up nameservers securely, so you > shouldn't use this an an excuse never to use hostnames. I disaggree that it is easy to make an authoritative server return poison. Even the BIND people are now recommending separating authoritative and caching servers. Even if the two were combined a correctly programmed cache can't be poisoned because it shouldn't trust glue from a server that isn't authoritative for the name server domain it is providing glue for. I don't know whether or not BIND still does this (trust glue unconditionally), but the cache I use doesn't. > > Efficiency. If there are a number of domain name entries you may only > > want to check them when reading hba.conf. This does break some useful > > things about using domain names in hba.conf. > > Personally, I think the best way to deal with the issue is, if the > connecting IP address is not found in hba.conf, do an in-addr.arpa > lookup on the IP address and see if you get a hostname. If you do, check > the hba.conf for that hostname. If the hba.conf has the hostname, then > you do a forward lookup on it and make sure that there's an A record > matching that IP address. > > Yes, it can slow things down significantly. But you can still always > just hardwire the IP addresses in hba.conf if you want to avoid the > slowdown and the addresses don't change often. However, if the addresses > do change often, this gives you the option of having the server follow > the changes automatically, at the price of a slowdown in connecting. I don't think the slow down is a big deal. It is just two dns lookups instead of one. The problem is that it limits you to only be able to use the domain in the PTR record when there may be other forward domains that would be preferred. However I don't think doing just forward lookups at connect time scales.
Bruno Wolff III <bruno@wolff.to> writes:
> .... However I don't think doing just forward
> lookups at connect time scales.
Is it necessary that it scale? AFAICS, putting DNS names in pg_hba.conf
would be a convenience feature for low-volume databases. People who are
trying to service lots of connections would put numbers in there anyway
for performance reasons. I'd prefer to go for simplicity here, and just
do the lookups on demand.
I think most of the objections that have been raised in this thread are
not very applicable to real-world uses. The hosts you are going to be
granting database access to are usually nearby ones, and the DNS server
you are going to be consulting is not only nearby but authoritative for
those names. So I think both the speed and security issues are being
overstated. Indeed we should mention them prominently in the docs, but
we should not overengineer the implementation.
regards, tom lane
I agree with this 100%. My plan was simply at connect time to loop through the stuff returned by getaddrinfo looking for a matching address. Risks in terms of security and connect time are matters for documentation, IMNSHO. andrew ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Bruno Wolff III" <bruno@wolff.to> Cc: "Curt Sampson" <cjs@cynic.net>; "PostgreSQL Hackers Mailing List" <pgsql-hackers@postgresql.org> Sent: Friday, May 09, 2003 8:50 AM Subject: Re: [HACKERS] CIDR in pg_hba.conf > Bruno Wolff III <bruno@wolff.to> writes: > > .... However I don't think doing just forward > > lookups at connect time scales. > > Is it necessary that it scale? AFAICS, putting DNS names in pg_hba.conf > would be a convenience feature for low-volume databases. People who are > trying to service lots of connections would put numbers in there anyway > for performance reasons. I'd prefer to go for simplicity here, and just > do the lookups on demand. > > I think most of the objections that have been raised in this thread are > not very applicable to real-world uses. The hosts you are going to be > granting database access to are usually nearby ones, and the DNS server > you are going to be consulting is not only nearby but authoritative for > those names. So I think both the speed and security issues are being > overstated. Indeed we should mention them prominently in the docs, but > we should not overengineer the implementation. >
I wish there were a time delay on email, so I wouldn't have sent the mail below :-) It just occurred to me that a possibly useful extension to using hostnames would be to allow wildcarded names, so "*.foo.com" would match anyone in the foo.com domain. To do this we would have to do reverse lookups after all, I think. andrew ----- Original Message ----- From: "Andrew Dunstan" <andrew@dunslane.net> > My plan was simply at connect time to loop through the stuff returned by > getaddrinfo looking for a matching address. Risks in terms of security and > connect time are matters for documentation, IMNSHO.
On Fri, 9 May 2003, Tom Lane wrote: > Bruno Wolff III <bruno@wolff.to> writes: > > .... However I don't think doing just forward > > lookups at connect time scales. > > Is it necessary that it scale? AFAICS, putting DNS names in pg_hba.conf > would be a convenience feature for low-volume databases. People who are > trying to service lots of connections would put numbers in there anyway > for performance reasons. I'd prefer to go for simplicity here, and just > do the lookups on demand. > > I think most of the objections that have been raised in this thread are > not very applicable to real-world uses. The hosts you are going to be > granting database access to are usually nearby ones, and the DNS server > you are going to be consulting is not only nearby but authoritative for > those names. So I think both the speed and security issues are being > overstated. Indeed we should mention them prominently in the docs, but > we should not overengineer the implementation. Agreed. I think there are two ways this type of entry might be used, one is in an area where IPs rarely change, but the sysadmin would prefer to have names in the pg_hba.conf anyway, so that on the rare occasion when they do, he can just restart the database if necessary, so looking them up at startup only is fine. the other possibility is for folks running in a DHCP environment, like say a corporate intranet. For those folks, it might well be that IPs could change every hour/day/week/month, and requiring the server to be "bumped" to see the new name -> IP resolution would be suboptimal. So, if the performance to perform a lookup on each connect isn't too big, I would lean towards that, since it works for both of the above scenarios.