Thread: pg_hba.conf hostname todo
Hello,
Per the TODO list:
Allow pg_hba.conf to specify host names along with IP addresses
Host name lookup could occur when the postmaster reads the pg_hba.conf
file, or when the backend starts. Another solution would be to reverse
lookup the connection IP and check that hostname against the host names
in pg_hba.conf. We could also then check that the host name maps to the
IP address.
I was considering trying to attack this for 8.3. My thoughts are the
following:
Allow one to specify a FQDN or a simple wild card DN. E.g;
*.commandprompt.com.
A valid entry would look like this:
host all all *.commandprompt.com trust
host all all www1.postgresql.org md5
Thoughts?
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
* Joshua D. Drake (jd@commandprompt.com) wrote:
> Allow pg_hba.conf to specify host names along with IP addresses
Excellent.
> Host name lookup could occur when the postmaster reads the pg_hba.conf
> file, or when the backend starts. Another solution would be to reverse
> lookup the connection IP and check that hostname against the host names
> in pg_hba.conf. We could also then check that the host name maps to the
> IP address.
I'm inclined towards doing the reverse-DNS of the connecting IP and then
checking that the forward of that matches.
> Allow one to specify a FQDN or a simple wild card DN. E.g;
> *.commandprompt.com.
>
> A valid entry would look like this:
>
> host all all *.commandprompt.com trust
> host all all www1.postgresql.org md5
>
> Thoughts?
While a wildcard does make sense (ie: www*.postgresql.org), I would
generally expect 'commandprompt.com' to mean '*.commandprompt.com'
implicitly.
Thanks!
Stephen
On Wed, 2006-12-27 at 16:41 -0500, Stephen Frost wrote:
> * Joshua D. Drake (jd@commandprompt.com) wrote:
> > Allow pg_hba.conf to specify host names along with IP addresses
>
> Excellent.
>
> > Host name lookup could occur when the postmaster reads the pg_hba.conf
> > file, or when the backend starts. Another solution would be to reverse
> > lookup the connection IP and check that hostname against the host names
> > in pg_hba.conf. We could also then check that the host name maps to the
> > IP address.
>
> I'm inclined towards doing the reverse-DNS of the connecting IP and then
> checking that the forward of that matches.
Hmm what if it doesn't? Which is the case any many scenario. My thoughts
are:
If www.commandprompt.com is allowed, then the ip address 207.173.200.129
is allowed to connect.
If we go the reverse way:
129.200.173.207.in-addr.arpa name = 129.commandprompt.com.
Which really isn't that useful imo.
>
> > Allow one to specify a FQDN or a simple wild card DN. E.g;
> > *.commandprompt.com.
> >
> > A valid entry would look like this:
> >
> > host all all *.commandprompt.com trust
> > host all all www1.postgresql.org md5
> >
> > Thoughts?
>
> While a wildcard does make sense (ie: www*.postgresql.org), I would
> generally expect 'commandprompt.com' to mean '*.commandprompt.com'
> implicitly.
Hmm interesting. I wouldn't expect that. I might
expect .commandprompt.com to mean *.commandprompt.com. But
commandprompt.com I would expect only whatever the A record returns as
commandprompt.com.
One thing I don't want to do is create a bunch of different style
syntaxes that are available :)
Sincerely,
Joshua D. Drake
>
> Thanks!
>
> Stephen
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
>>> Host name lookup could occur when the postmaster reads the pg_hba.conf >>> file, or when the backend starts. Another solution would be to reverse >>> lookup the connection IP and check that hostname against the host names >>> in pg_hba.conf. We could also then check that the host name maps to the >>> IP address. >> I'm inclined towards doing the reverse-DNS of the connecting IP and then >> checking that the forward of that matches. > > Hmm what if it doesn't? Which is the case any many scenario. My thoughts > are: > > If www.commandprompt.com is allowed, then the ip address 207.173.200.129 > is allowed to connect. > > If we go the reverse way: > > 129.200.173.207.in-addr.arpa name = 129.commandprompt.com. > > Which really isn't that useful imo. Just make absolutely sure you don't trust the *reverse* without double-checking the forward. Trusting the forward without double-checking the reverse seems reasonable. Though in a situation like yours, I'd personally recommend either putting "129.commandprompt.com" in the pg_hba.conf, or better yet change the reverse to actually be meaningful ;-) >>> Allow one to specify a FQDN or a simple wild card DN. E.g; >>> *.commandprompt.com. >>> >>> A valid entry would look like this: >>> >>> host all all *.commandprompt.com trust >>> host all all www1.postgresql.org md5 >>> >>> Thoughts? >> While a wildcard does make sense (ie: www*.postgresql.org), I would >> generally expect 'commandprompt.com' to mean '*.commandprompt.com' >> implicitly. > > Hmm interesting. I wouldn't expect that. I might > expect .commandprompt.com to mean *.commandprompt.com. But > commandprompt.com I would expect only whatever the A record returns as > commandprompt.com. > > One thing I don't want to do is create a bunch of different style > syntaxes that are available :) My vote is for specifically requiring "*.commandprompt.com" if you want a wildcard. That leaves any guesswork out of it. commandprompt.com should *definitly* not be "*.commandprompt.com" IMHO - having A records on the domain is way too common these days. (And I think it's a lot less frowned upon than it once used to be, given that so many people use it now) And to repeat the above - for wildcards you *must* do both reverse and forward lookups on the connection. This makes it impossible/impractical to parse it during pg_hba.conf load which is in the TODO item, but I don't really see the point of that part anyway. //Magnus
* Joshua D. Drake (jd@commandprompt.com) wrote:
> On Wed, 2006-12-27 at 16:41 -0500, Stephen Frost wrote:
> > I'm inclined towards doing the reverse-DNS of the connecting IP and then
> > checking that the forward of that matches.
>
> Hmm what if it doesn't? Which is the case any many scenario. My thoughts
> are:
If it doesn't then it's not allowed, of course. :)
> If www.commandprompt.com is allowed, then the ip address 207.173.200.129
> is allowed to connect.
>
> If we go the reverse way:
>
> 129.200.173.207.in-addr.arpa name = 129.commandprompt.com.
>
> Which really isn't that useful imo.
While I agree that the way your reverse DNS has been done isn't very
useful, I don't feel that such a setup should be encouraged or
accomedated by an authorization system. There's a couple of reasons
to go with reverse DNS:
#1: www.commandprompt.com could legitimately map to multiple IP
addresses
#2: You may not be able to see all the addresses it maps to at a given
time without a bunch of work (potentially requiring multiple look-ups)
#3: There's pretty much no circumstance which makes sense for an IP
address to reverse to multiple host names
#4: Even in the case mentioned, 129.commandprompt.com does resolve back
to the appropriate IP, so the re-check would succeed (but you'd have to
put 129.commandprompt.com into pg_hba, or change it to 'www129' and put
'www*' in)
#5: It's what Kerberos does (used on >18,000 hosts at A*cough*OL). :)
> > While a wildcard does make sense (ie: www*.postgresql.org), I would
> > generally expect 'commandprompt.com' to mean '*.commandprompt.com'
> > implicitly.
>
> Hmm interesting. I wouldn't expect that. I might
> expect .commandprompt.com to mean *.commandprompt.com. But
> commandprompt.com I would expect only whatever the A record returns as
> commandprompt.com.
>
> One thing I don't want to do is create a bunch of different style
> syntaxes that are available :)
Sure. Either way for this is alright with me, really. Just be sure to
document it clearly whichever way you decide to go. :)
Thanks,
Stephen
On Dec 27, 2006, at 1:47 PM, Joshua D. Drake wrote: > On Wed, 2006-12-27 at 16:41 -0500, Stephen Frost wrote: >> * Joshua D. Drake (jd@commandprompt.com) wrote: >>> Allow pg_hba.conf to specify host names along with IP addresses >> >> Excellent. >> >>> Host name lookup could occur when the postmaster reads the >>> pg_hba.conf >>> file, or when the backend starts. Another solution would be to >>> reverse >>> lookup the connection IP and check that hostname against the host >>> names >>> in pg_hba.conf. We could also then check that the host name maps >>> to the >>> IP address. >> Doing the DNS at connect time, not startup time is the right thing to do. The main reason to use hostnames rather than IP addresses (or domain wildcards vs CIDR blocks) is because you're expecting the mapping to change. You really don't want to add "restart all our postgresql instances" to the DNS managers "I changed a hostname" checklist. >> I'm inclined towards doing the reverse-DNS of the connecting IP >> and then >> checking that the forward of that matches. > > Hmm what if it doesn't? Which is the case any many scenario. My > thoughts > are: > > If www.commandprompt.com is allowed, then the ip address > 207.173.200.129 > is allowed to connect. DNS is cheap. For the simple case it wouldn't be too hard to expand all the given hostnames at connect time, but there's a problem ... > If we go the reverse way: > > 129.200.173.207.in-addr.arpa name = 129.commandprompt.com. > > Which really isn't that useful imo. ... unfortunately, you need to do it that way if you want to support wildcards, as there's no way to expand *.example.com to a list of IP addresses. > >> >>> Allow one to specify a FQDN or a simple wild card DN. E.g; >>> *.commandprompt.com. >>> >>> A valid entry would look like this: >>> >>> host all all *.commandprompt.com trust >>> host all all www1.postgresql.org md5 >>> >>> Thoughts? >> >> While a wildcard does make sense (ie: www*.postgresql.org), I would >> generally expect 'commandprompt.com' to mean '*.commandprompt.com' >> implicitly. > > Hmm interesting. I wouldn't expect that. I might > expect .commandprompt.com to mean *.commandprompt.com. But > commandprompt.com I would expect only whatever the A record returns as > commandprompt.com. > One thing I don't want to do is create a bunch of different style > syntaxes that are available :) tcp_wrappers (/etc/hosts.allow and friends) are one fairly widely used standard for this, and one that's mostly compatible with the existing usage for dotted quads, I think. It uses ".example.com" to match anything that ends in "example.com". (If you're going down that road you can also have a "host" that begins with a "/" to refer to an external list of filenames, but that way may lie madness.) Cheers, Steve
On Wed, 2006-12-27 at 17:02 -0500, Stephen Frost wrote:
> * Joshua D. Drake (jd@commandprompt.com) wrote:
> > On Wed, 2006-12-27 at 16:41 -0500, Stephen Frost wrote:
> > > I'm inclined towards doing the reverse-DNS of the connecting IP and then
> > > checking that the forward of that matches.
> >
> > Hmm what if it doesn't? Which is the case any many scenario. My thoughts
> > are:
>
> If it doesn't then it's not allowed, of course. :)
>
> > If www.commandprompt.com is allowed, then the ip address 207.173.200.129
> > is allowed to connect.
> >
> > If we go the reverse way:
> >
> > 129.200.173.207.in-addr.arpa name = 129.commandprompt.com.
> >
> > Which really isn't that useful imo.
>
> While I agree that the way your reverse DNS has been done isn't very
> useful, I don't feel that such a setup should be encouraged or
> accomedated by an authorization system.
Well from the lazy hat of sysadmin. The *only* reason I even have
reverse dns is to deal with smtp servers that won't accept email unless
the ip has a reverse ;)
> There's a couple of reasons
> to go with reverse DNS:
>
> #1: www.commandprompt.com could legitimately map to multiple IP
> addresses
Agreed, I was thinking about that. The only thing I could come up with
is a list that would be checked (think where foo IN ())
>
> #2: You may not be able to see all the addresses it maps to at a given
> time without a bunch of work (potentially requiring multiple look-ups)
Hmm... I would have to check that.
>
> #4: Even in the case mentioned, 129.commandprompt.com does resolve back
> to the appropriate IP, so the re-check would succeed (but you'd have to
> put 129.commandprompt.com into pg_hba, or change it to 'www129' and put
> 'www*' in)
My proposal does not accept that syntax. I think www* would be insane.
> > syntaxes that are available :)
>
> Sure. Either way for this is alright with me, really. Just be sure to
> document it clearly whichever way you decide to go. :)
Like the stone tablets of God.
Joshua D. Drake
>
> Thanks,
>
> Stephen
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Joshua D. Drake wrote: > Hello, > > Per the TODO list: > > Allow pg_hba.conf to specify host names along with IP addresses > > Host name lookup could occur when the postmaster reads the pg_hba.conf > file, or when the backend starts. Another solution would be to reverse > lookup the connection IP and check that hostname against the host names > in pg_hba.conf. We could also then check that the host name maps to the > IP address. > > > I was considering trying to attack this for 8.3. My thoughts are the > following: > > Allow one to specify a FQDN or a simple wild card DN. E.g; > *.commandprompt.com. > > A valid entry would look like this: > > host all all *.commandprompt.com trust > host all all www1.postgresql.org md5 > Before we rehearse the discussion we had in June again, please review it. It ended on these sensible words from Tom at http://archives.postgresql.org/pgsql-hackers/2006-02/msg00550.php : > > Personally, I doubt there's any great use case for DNS names. Like Tom > > says, if it involves much more that removing the AI_NUMERICHOST hint > > then let's forget it. > > Perhaps more to the point: let's do that and wait to see if the field > demand justifies expending lots of sweat on anything smarter. Given > that we've gone this long with only allowing numeric IPs in pg_hba.conf, > I suspect we'll find that few people really care. > cheers andrew
* Andrew Dunstan (andrew@dunslane.net) wrote: > Before we rehearse the discussion we had in June again, please review > it. It ended on these sensible words from Tom at > http://archives.postgresql.org/pgsql-hackers/2006-02/msg00550.php : I'd have to disagree with this sentiment and agree with Gregory's followup here: http://archives.postgresql.org/pgsql-hackers/2006-02/msg00553.php > >> Personally, I doubt there's any great use case for DNS names. Like Tom > >> says, if it involves much more that removing the AI_NUMERICHOST hint > >> then let's forget it. > > > >Perhaps more to the point: let's do that and wait to see if the field > >demand justifies expending lots of sweat on anything smarter. Given > >that we've gone this long with only allowing numeric IPs in pg_hba.conf, > >I suspect we'll find that few people really care. I don't see that this argument really makes all that much sense- not doing it properly and then waiting to see if people use it isn't exactly how I'd go about finding out if people want it. Thanks, Stephen
Stephen Frost wrote: > * Andrew Dunstan (andrew@dunslane.net) wrote: > >> Before we rehearse the discussion we had in June again, please review >> it. It ended on these sensible words from Tom at >> http://archives.postgresql.org/pgsql-hackers/2006-02/msg00550.php : >> > > I'd have to disagree with this sentiment and agree with Gregory's > followup here: > http://archives.postgresql.org/pgsql-hackers/2006-02/msg00553.php > I don't know that there is a contradiction. Frankly, any auth scheme based much on the client address or name is suspect, in my view. Organisations like those he refers to can simply put in a wildcard rule along with strong auth requirements and never have to bother. This is not like having to specify what address a client has to connect to. > >>>> Personally, I doubt there's any great use case for DNS names. Like Tom >>>> says, if it involves much more that removing the AI_NUMERICHOST hint >>>> then let's forget it. >>>> >>> Perhaps more to the point: let's do that and wait to see if the field >>> demand justifies expending lots of sweat on anything smarter. Given >>> that we've gone this long with only allowing numeric IPs in pg_hba.conf, >>> I suspect we'll find that few people really care. >>> > > I don't see that this argument really makes all that much sense- not > doing it properly and then waiting to see if people use it isn't exactly > how I'd go about finding out if people want it. > > It depends on what you define as "properly". If you want to include the use of wildcards, then you need a heck of a lot more logic and processing. But we've hardly had people banging on the doors demanding this. cheers andrew
Stephen Frost <sfrost@snowman.net> writes:
> While a wildcard does make sense (ie: www*.postgresql.org), I would
> generally expect 'commandprompt.com' to mean '*.commandprompt.com'
> implicitly.
No, that would be a really bad idea. It's not unlikely that
commandprompt.com refers to a specific host. If you implicitly allow it
to match *.commandprompt.com then there's no way to specify "connections
from just this host, not the whole domain underneath it".
I'm not sure that DNS wildcards are appropriate at all, but if they are
we should definitely require them to be written as explicit wildcards,
not have that happen silently behind the DBA's back.
regards, tom lane