Hostnames in pg_hba.conf
in [PgSql]
|
From: Bart Samwel on 11 Feb 2010 17:12 On Thu, Feb 11, 2010 at 23:01, Mark Mielke <mark(a)mark.mielke.cc> wrote: > On 02/11/2010 04:54 PM, Bart Samwel wrote: > > ISSUE #3: Multiple hostnames? >> >> Currently, a pg_hba entry lists an IP / netmask combination. I would >> suggest allowing lists of hostnames in the entries, so that you can at least >> mimic the "match multiple hosts by a single rule". Any reason not to do >> this? >> >> >> I'm mixed. In some situations, I've wanted to put multiple IP/netmask. I >> would say that if multiple names are supported, then multiple IP/netmask >> should be supported. But, this does make the lines unwieldy beyond two or >> three. This direction leans towards the capability to define "host classes", >> where the rules allows the host class, and the host class can have a list of >> hostnames. >> > > Yes, but before you know it people will ask for being able to specify > multiple host classes. :-) Quite simply put, with a single subnet you can > allow multiple hosts in. Allowing only a single hostname is a step backward > from that, so adding support for multiple hostnames could be useful if > somebody is replacing subnets with hostname-based configuration. > > > This implies two aspects which may not be true: > > 1) All hosts that I want to allow belong to the same subnet. > 2) If I trust one host on the subnet, then I trust all hosts on the > subnet. > > While the above two points are often true, they are not universally true. > I don't think we're talking about the same thing here. I wasn't suggesting doing hostname-plus-netmask. NO! I was suggesting that where a lazy sysadmin would previously configure by subnet, they might switch to more fine-grained hostname-based configuration ONLY IF it doesn't require duplicating every line in pg_hba.conf for every host in the subnet. 2) What will you do if they specify a hostname and a netmask? This seems > like a convenient way of saying "everybody on the same subnet as NAME." > Not supported. Either an IP address / netmask combo, or a hostname, but not both. I wouldn't want to recommend hardcoding something such as netmasks (which are definitely subnet dependent) in combination with something as volatile as a host name -- move it to a different subnet, and you might allow a whole bigger subnet than you intended. If they want to specify a netmask, then they should just use hardcoded IPs as well. Ah yes, I recall this from a previous thread. I think I also disagreed on > the other thread. :-) > > I thought of a use for reverse lookup - it would allow wild card hostnames. > Still, that's an advanced feature that might be for later... :-) > I think wildcards are interesting, but I have yet to see an actual use case other than "it's cool and very generalized". In my mind (tell me if I'm wrong), the most common type of PostgreSQL authentication setup is within a local network within an organization. There, you either authorize an entire subnet ("the entire server park" or "all client PCs") or you authorize specific hosts (single IP address). The wildcard case is for replacing the first case, but for that case, subnets are usually just fine. I'm trying to target the second case here. Cheers, Bart
From: Mark Mielke on 11 Feb 2010 23:51 On 02/11/2010 09:38 PM, Euler Taveira de Oliveira wrote: > Mark Mielke escreveu: > >> Of course, then I'll ask for the ability to simplify specifying multiple >> databases: >> >> > We already support multiple users and/or databases for a single pg_hba.conf > line ... > Is there a reason you trimmed out my points about specifying "classes" as a list of data (host, db, user) and using it in host lines? :-) "Simplifying specifying multiple databases" in the sense of if a particular line has to list 10 databases, 10 users, and 10 hostnames, it would be most convenient to specify 3 "classes" with 10 records each, followed by one host line, instead of have 10 lines with 20 entries on it or 1000 lines... :-) Cheers, mark -- Mark Mielke<mark(a)mielke.cc> -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bart Samwel on 11 Feb 2010 16:54 On Thu, Feb 11, 2010 at 16:36, Mark Mielke <mark(a)mark.mielke.cc> wrote: > On 02/11/2010 08:13 AM, Bart Samwel wrote: > ISSUE #2: Reverse lookup? > > There was a suggestion on the TODO list on the wiki, which basically said > that maybe we could use reverse lookup to find "the" hostname and then check > for that hostname in the list. I think that won't work, since IPs can go by > many names and may not support reverse lookup for some hostnames (/etc/hosts > anybody?). Furthermore, due to the top-to-bottom processing of pg_hba.conf, > you CANNOT SKIP entries that might possibly match. For instance, if the > third line is for host "foo.example.com" and the fifth line is for " > bar.example.com", both lines may apply to the same IP, and you still HAVE > to check the first one, even if reverse lookup turns up the second host > name. So it doesn't save you any lookups, it just costs an extra one. > > > I don't see a need to do a reverse lookup. Reverse lookups are sometimes > done as a verification check, in the sense that it's cheap to get a map from > NAME -> IP, but sometimes it is much harder to get the reverse map from IP > -> NAME. However, it's not a reliable check as many legitimate users have > trouble getting a reverse map from IP -> NAME. It also doesn't same anything > as IP -> NAME lookups are a completely different set of name servers, and > these name servers are not always optimized for speed as IP -> NAME lookups > are less common than NAME -> IP. Finally, if one finds a map from IP -> > NAME, that doesn't prove that a map from NAME -> IP exists, so using *any* > results from IP -> NAME is questionable. > > I think reverse lookups are unnecessary and undesirable. > > > ISSUE #3: Multiple hostnames? > > Currently, a pg_hba entry lists an IP / netmask combination. I would > suggest allowing lists of hostnames in the entries, so that you can at least > mimic the "match multiple hosts by a single rule". Any reason not to do > this? > > > I'm mixed. In some situations, I've wanted to put multiple IP/netmask. I > would say that if multiple names are supported, then multiple IP/netmask > should be supported. But, this does make the lines unwieldy beyond two or > three. This direction leans towards the capability to define "host classes", > where the rules allows the host class, and the host class can have a list of > hostnames. > Yes, but before you know it people will ask for being able to specify multiple host classes. :-) Quite simply put, with a single subnet you can allow multiple hosts in. Allowing only a single hostname is a step backward from that, so adding support for multiple hostnames could be useful if somebody is replacing subnets with hostname-based configuration. Two other aspects I don't see mentioned: > > 1) What will you do for hostnames that have multiple IP addresses? Will you > accept all IP addresses as being valid? > Yes, all addresses returned by (pg_)getaddrinfo will be considered valid. Most importantly, this ensures that if a host has an IPv4 and an IPv6 address they are both accepted. Plus, if there are multiple addresses, we have no clue of figuring out which address is "the" address. :-) > 2) What will you do if they specify a hostname and a netmask? This seems > like a convenient way of saying "everybody on the same subnet as NAME." > Not supported. Either an IP address / netmask combo, or a hostname, but not both. I wouldn't want to recommend hardcoding something such as netmasks (which are definitely subnet dependent) in combination with something as volatile as a host name -- move it to a different subnet, and you might allow a whole bigger subnet than you intended. If they want to specify a netmask, then they should just use hardcoded IPs as well. Cheers, Bart
From: Peter Eisentraut on 12 Feb 2010 10:33 On tor, 2010-02-11 at 14:13 +0100, Bart Samwel wrote: > I've been working on a patch to add hostname support to pg_hba.conf. > It's not ready for public display yet, but I would just like to run a > couple of issues / discussion points past everybody. It might be good to review Apache's hostname-based access control: http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#allow -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Pages: 1 2 Prev: servicos especializados de informatica vitoria-es 13109 Next: [HACKERS] Bug on pg_lesslog |