Re: Why don't we allow DNS names in pg_hba.conf?

I was reminded of $subject by
http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php

While I haven't tried it, I suspect that allowing a DNS host name
would take little work (basically removing the AI_NUMERICHOST flag
passed to getaddrinfo in hba.c). There was once a good reason not
to allow it: slow DNS lookups would lock up the postmaster. But
now that we do this work in an already-forked backend, with an overall
timeout that would catch any indefinite blockage, I don't see a good
reason why we shouldn't let people use DNS names.

Thoughts?

regards, tom lane

On Sun, 1 Jan 2006, Tom Lane wrote:

> I was reminded of $subject by
> http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php
>
> While I haven't tried it, I suspect that allowing a DNS host name
> would take little work (basically removing the AI_NUMERICHOST flag
> passed to getaddrinfo in hba.c). There was once a good reason not
> to allow it: slow DNS lookups would lock up the postmaster. But
> now that we do this work in an already-forked backend, with an overall
> timeout that would catch any indefinite blockage, I don't see a good
> reason why we shouldn't let people use DNS names.
>
> Thoughts?

Security?

Employee adds his DNS to pg_hba.conf, becomes disgruntled employee, moves
to different IP and same name, and can still access your database?

What about "DNS hijacking/forging"? I don't know how hard it is to do,
but if one of the upstream network provides puts in a 'filter' for port 53
(DNS) and starts feeding you incorrect data, so that they can access your
databases?

Both are relatively extreme, and in both bases, the 'attacker' would have
to have previous knowledge (ie. disgruntled ex employee) but DNS !=
trusted IP ... then again, it may be possible to hijack/forge the IP
itself, in which case, there is no difference ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Sun, Jan 01, 2006 at 02:50:37PM -0400, Marc G. Fournier wrote:
> Employee adds his DNS to pg_hba.conf, becomes disgruntled employee, moves
> to different IP and same name, and can still access your database?

I think it depends how you do the check. You can either do a forward
lookup from the name and match that to the IP. Or you can do a reverse
lookup on the IP to match the name. Or both.

To work around either requires hijacking DNS but which servers varies.
If you've got the entries in /etc/hosts that makes hijacking harder.

I'm thinking something like tcpwrappers would be an example here. They
have a paranoid mode where your reverse and forward have to match.
Something to consider.

For the user in referred to thread: SSH tunnelling. I wonder if there's
a way we can make that easier to setup...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Marc G. Fournier wrote:

> On Sun, 1 Jan 2006, Tom Lane wrote:
>
>> I was reminded of $subject by
>> http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php
>>
>> While I haven't tried it, I suspect that allowing a DNS host name
>> would take little work (basically removing the AI_NUMERICHOST flag
>> passed to getaddrinfo in hba.c). There was once a good reason not
>> to allow it: slow DNS lookups would lock up the postmaster. But
>> now that we do this work in an already-forked backend, with an overall
>> timeout that would catch any indefinite blockage, I don't see a good
>> reason why we shouldn't let people use DNS names.
>>
>> Thoughts?
>
>
> Security?

I'd bet most pg_hba.conf entries will be (private) networks, not hosts.
Since private networks defined in DNS are probably quite rare, only few
people could benefit.

Those who *do* define specific host entries, are probably quite security
aware. They might find DNS safe for their purposes, but they'd probably
like a function that shows the resulting hba entries after DNS resolution.

Routers/firewalls that allow DNS names will usually resolve them
immediately, and store the IP addresses.

Regards,
Andreas

"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> On Sun, 1 Jan 2006, Tom Lane wrote:
>> ... I don't see a good
>> reason why we shouldn't let people use DNS names.

> Security?

Possibly, but if you're worried about that sort of attack you just don't
use DNS names in pg_hba.conf. Certainly it'd be worth putting a warning
in the manual about the risks of referring to DNS servers that aren't
directly under your control. But that doesn't seem like a reason not to
provide the feature for those who want it.

regards, tom lane

On Jan 1, 2006, at 2:02 PM, Martijn van Oosterhout wrote:

> For the user in referred to thread: SSH tunnelling. I wonder if
> there's
> a way we can make that easier to setup...

Making this easier and transparent would be nice, but I would still
vote to allow DNS names in pg_hba.conf.

SSH tunneling implies another level of software, user accounts, and
permissions. It would be nice to handle the entire sphere of users
and permissions from within PostgreSQL. For database access
requirements, I would much rather allow DNS names in pg_hba.conf than
provide SSH access.

John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL

Am Sonntag, 1. Januar 2006 19:30 schrieb Tom Lane:
> I don't see a good
> reason why we shouldn't let people use DNS names.

I generally support this, but I wonder if this could have strange effects if a
name resolves to more than one IP address or even an IPv4 and an IPv6
address.

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Am Sonntag, 1. Januar 2006 19:30 schrieb Tom Lane:
>> I don't see a good
>> reason why we shouldn't let people use DNS names.

> I generally support this, but I wonder if this could have strange
> effects if a name resolves to more than one IP address or even an IPv4
> and an IPv6 address.

That's a good point: we'd have to be prepared to match the actual remote
IP address to more than one return value from getaddrinfo, so the change
wouldn't be a one-liner after all. It still seems like a pretty
localized change though.

regards, tom lane

Tom Lane wrote:

>I was reminded of $subject by
>http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php
>
>While I haven't tried it, I suspect that allowing a DNS host name
>would take little work (basically removing the AI_NUMERICHOST flag
>passed to getaddrinfo in hba.c). There was once a good reason not
>to allow it: slow DNS lookups would lock up the postmaster. But
>now that we do this work in an already-forked backend, with an overall
>timeout that would catch any indefinite blockage, I don't see a good
>reason why we shouldn't let people use DNS names.
>
>Thoughts?
>
>
>
>

We debated this back in May 2003 - I was going to do it but it got lost
among other stuff. Still worth doing, I think.

cheers

andrew

I also support this change. My clients have tended to move
machines and networks around a lot as well as move databases from machine
to machine. It would be nice to let the network gurus concentrate
on getting the dns servers up and correct and leverage that
work instead of having to change pg_hba.conf when these changes
occur.

elein
elein(at)varlena(dot)com

On Sun, Jan 01, 2006 at 01:30:46PM -0500, Tom Lane wrote:
> I was reminded of $subject by
> http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php
>
> While I haven't tried it, I suspect that allowing a DNS host name
> would take little work (basically removing the AI_NUMERICHOST flag
> passed to getaddrinfo in hba.c). There was once a good reason not
> to allow it: slow DNS lookups would lock up the postmaster. But
> now that we do this work in an already-forked backend, with an overall
> timeout that would catch any indefinite blockage, I don't see a good
> reason why we shouldn't let people use DNS names.
>
> Thoughts?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>

Yes, it would be good to implement this. A warning about security and
(possible) slow connections due to name resolution issues should be placed in
the docs.
Regards

paolo

elein <elein(at)varlena(dot)com> ha scritto

> I also support this change. My clients have tended to move
> machines and networks around a lot as well as move databases from machine
> to machine. It would be nice to let the network gurus concentrate
> on getting the dns servers up and correct and leverage that
> work instead of having to change pg_hba.conf when these changes
> occur.
>
> elein
> elein(at)varlena(dot)com
>
> On Sun, Jan 01, 2006 at 01:30:46PM -0500, Tom Lane wrote:
> > I was reminded of $subject by
> > http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php
> >
> > While I haven't tried it, I suspect that allowing a DNS host name
> > would take little work (basically removing the AI_NUMERICHOST flag
> > passed to getaddrinfo in hba.c). There was once a good reason not
> > to allow it: slow DNS lookups would lock up the postmaster. But
> > now that we do this work in an already-forked backend, with an overall
> > timeout that would catch any indefinite blockage, I don't see a good
> > reason why we shouldn't let people use DNS names.
> >
> > Thoughts?
> >
> > regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 9: In versions below 8.0, the planner will ignore your desire to
> > choose an index scan if your joining column's datatypes do not
> > match
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

On Sun, 1 Jan 2006, Andreas Pflug wrote:

>>> While I haven't tried it, I suspect that allowing a DNS host name
>>> would take little work (basically removing the AI_NUMERICHOST flag
>>> passed to getaddrinfo in hba.c). There was once a good reason not
>>> to allow it: slow DNS lookups would lock up the postmaster. But
>>> now that we do this work in an already-forked backend, with an overall
>>> timeout that would catch any indefinite blockage, I don't see a good
>>> reason why we shouldn't let people use DNS names.
[snip]
>
> Routers/firewalls that allow DNS names will usually resolve them immediately,
> and store the IP addresses.

I think it's a great idea to make DNS names an option in pg_hba.conf.
However, I think we're talking about two fairly different features here.

(1) What Tom proposed is that we store the hostname and do a new DNS
lookup for every connection. That could be useful in certain situations,
but I wouldn't use it for a busy production server. The additional time
for DNS lookups (even with a fast local caching nameserver) would not be a
price I'd want to pay for the convenience. In a development environment,
it could be just the ticket, though.

(2) As Andreas mentioned, firewalls commonly do the DNS lookups when they
read their configuration, and store the IP addresses. If we did this,
you'd presumably only have to reload the postmaster configuration to cause
the DNS lookups to be done again, but until then they'd be static and as
fast as using actual IP addresses.

If both were implemented, I'm not sure how you'd indicate which method you
want on any given pg_hba.conf line.

If we were only to have one of these, I'd prefer (2). You could always set
up a cron job to reload the postmaster config hourly or daily, to keep the
DNS lookups from getting too stale.

Jon

--
Jon Jensen
End Point Corporation
http://www.endpoint.com/
Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ...

On 1/2/06, Jon Jensen <jon(at)endpoint(dot)com> wrote:
> On Sun, 1 Jan 2006, Andreas Pflug wrote:
>
> >>> While I haven't tried it, I suspect that allowing a DNS host name
> >>> would take little work (basically removing the AI_NUMERICHOST flag
> >>> passed to getaddrinfo in hba.c). There was once a good reason not
> >>> to allow it: slow DNS lookups would lock up the postmaster. But
> >>> now that we do this work in an already-forked backend, with an overall
> >>> timeout that would catch any indefinite blockage, I don't see a good
> >>> reason why we shouldn't let people use DNS names.
> [snip]
> >
> > Routers/firewalls that allow DNS names will usually resolve them immediately,
> > and store the IP addresses.
>
> I think it's a great idea to make DNS names an option in pg_hba.conf.
> However, I think we're talking about two fairly different features here.
>
> (1) What Tom proposed is that we store the hostname and do a new DNS
> lookup for every connection. That could be useful in certain situations,
> but I wouldn't use it for a busy production server. The additional time
> for DNS lookups (even with a fast local caching nameserver) would not be a
> price I'd want to pay for the convenience. In a development environment,
> it could be just the ticket, though.

IMHO, this is the price you pay for using DNS.

>
> (2) As Andreas mentioned, firewalls commonly do the DNS lookups when they
> read their configuration, and store the IP addresses. If we did this,
> you'd presumably only have to reload the postmaster configuration to cause
> the DNS lookups to be done again, but until then they'd be static and as
> fast as using actual IP addresses.
>
> If both were implemented, I'm not sure how you'd indicate which method you
> want on any given pg_hba.conf line.
>
> If we were only to have one of these, I'd prefer (2). You could always set
> up a cron job to reload the postmaster config hourly or daily, to keep the
> DNS lookups from getting too stale.

If we're going to use an external facility, I'd vote for using it as a
black box via the API it was designed with and not doing any caching
tricks, especially if those tricks involve reloading the config file
to make changes visible that would be seen if the facility were used
"correctly". I guess I just see it as a "correct vs. fast" decision.
If caching were to be used, expiry should be based on the TTL for the
DNS record, and not a reload of our config.

.... just my $0.02.

>
> Jon
>
> --
> Jon Jensen
> End Point Corporation
> http://www.endpoint.com/
> Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ...
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

--
Mike Rylander
mrylander(at)gmail(dot)com
GPLS -- PINES Development
Database Developer
http://open-ils.org

Jon Jensen <jon(at)endpoint(dot)com> writes:
> (1) What Tom proposed is that we store the hostname and do a new DNS
> lookup for every connection. That could be useful in certain situations,
> but I wouldn't use it for a busy production server. The additional time
> for DNS lookups (even with a fast local caching nameserver) would not be a
> price I'd want to pay for the convenience.

Can you demonstrate that this is actually a serious concern next to the
total time spent launching a backend? I can't measure any real change
in total time for "psql -l" when log_hostname is enabled, which should
be a comparable hit.

I started out proposing a one-line change. The odds of this ever
getting done drop by an order of magnitude every time someone proposes
another order-of-magnitude increase in the work required...

regards, tom lane

On Mon, 2 Jan 2006, Tom Lane wrote:

>> (1) What Tom proposed is that we store the hostname and do a new DNS
>> lookup for every connection. That could be useful in certain situations,
>> but I wouldn't use it for a busy production server. The additional time
>> for DNS lookups (even with a fast local caching nameserver) would not be a
>> price I'd want to pay for the convenience.
>
> Can you demonstrate that this is actually a serious concern next to the
> total time spent launching a backend? I can't measure any real change
> in total time for "psql -l" when log_hostname is enabled, which should
> be a comparable hit.

The difference is negligible when using a UNIX socket (of course) or names
listed in /etc/hosts. But it's certainly slower in my tests if you really
use DNS. On a run of 1000 connections doing "psql -l", it takes 18.89s
without the DNS lookup for log_hostname, and 31.5s with. Or run as a
one-off, it's 0.032 to 0.041s. Enough to make a difference on a busy
server taking connections only over a local network.

However, if I consider the likely use cases, this feature probably isn't
important to such highly speed-sensitive servers anyway. And for those who
want every last bit of speed possible, /etc/hosts still allows them to use
this feature without a noticeable speed penalty. If the documentation
mentions that DNS lookups are done for every request if you choose to use
hostnames in pg_hba.conf, I think that's fair enough.

> I started out proposing a one-line change. The odds of this ever
> getting done drop by an order of magnitude every time someone proposes
> another order-of-magnitude increase in the work required...

It sounds like it's beyond a one-line change anyway, due to the
possibility of multiple IP addresses coming back.

But I agree that complicating this simple feature is overkill. The
database is not a firewall, and doesn't have a firewall's speed due to
connection overhead anyway.

Jon

--
Jon Jensen
End Point Corporation
http://www.endpoint.com/
Software development with Interchange, Perl, PostgreSQL, Apache, Linux, ...

Jon Jensen <jon(at)endpoint(dot)com> writes:
> On Mon, 2 Jan 2006, Tom Lane wrote:
>> Can you demonstrate that this is actually a serious concern next to the
>> total time spent launching a backend? I can't measure any real change
>> in total time for "psql -l" when log_hostname is enabled, which should
>> be a comparable hit.

> The difference is negligible when using a UNIX socket (of course) or names
> listed in /etc/hosts. But it's certainly slower in my tests if you really
> use DNS. On a run of 1000 connections doing "psql -l", it takes 18.89s
> without the DNS lookup for log_hostname, and 31.5s with. Or run as a
> one-off, it's 0.032 to 0.041s.

Um --- I was testing a local-loopback connection, but now that I look at
the nsswitch.conf setup, it was going to /etc/hosts for that case.
Coming across the network so that a real DNS lookup is forced, there
seems to be a difference of about 4ms (note this is with a local DNS
daemon). I don't think that's significant. If it is, you've got other
performance problems anyway, and should switch to pooled connections to
reduce the number of backend launches.

regards, tom lane

On Sun, Jan 01, 2006 at 09:03:00PM +0100, Andreas Pflug wrote:
> Marc G. Fournier wrote:
>
> >On Sun, 1 Jan 2006, Tom Lane wrote:
> >
> >>I was reminded of $subject by
> >>http://archives.postgresql.org/pgsql-admin/2006-01/msg00002.php
> >>
> >>While I haven't tried it, I suspect that allowing a DNS host name
> >>would take little work (basically removing the AI_NUMERICHOST flag
> >>passed to getaddrinfo in hba.c). There was once a good reason not
> >>to allow it: slow DNS lookups would lock up the postmaster. But
> >>now that we do this work in an already-forked backend, with an overall
> >>timeout that would catch any indefinite blockage, I don't see a good
> >>reason why we shouldn't let people use DNS names.
> >>
> >>Thoughts?
> >
> >
> >Security?
>
>
> I'd bet most pg_hba.conf entries will be (private) networks, not hosts.
> Since private networks defined in DNS are probably quite rare, only few
> people could benefit.
>
> Those who *do* define specific host entries, are probably quite security
> aware. They might find DNS safe for their purposes, but they'd probably
> like a function that shows the resulting hba entries after DNS resolution.

I don't know if the normal DNS libraries allow this, but it would be
cool if you could specify that an entry in pg_hba.conf could be looked
up from /etc/hosts, but not from generic DNS. AFAIK that would eliminate
the possibility of spoofing.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

--- "Jim C. Nasby" <jnasby(at)pervasive(dot)com> escreveu:

> I don't know if the normal DNS libraries allow this, but it would be
> cool if you could specify that an entry in pg_hba.conf could be
> looked
> up from /etc/hosts, but not from generic DNS. AFAIK that would
> eliminate
> the possibility of spoofing.
>
Take a look at 'man /etc/host.conf'.

Euler Taveira de Oliveira
euler[at]yahoo_com_br

_______________________________________________________
Yahoo! doce lar. Faça do Yahoo! sua homepage.
http://br.yahoo.com/homepageset.html

Euler Taveira de Oliveira wrote:

>--- "Jim C. Nasby" <jnasby(at)pervasive(dot)com> escreveu:
>
>
>
>>I don't know if the normal DNS libraries allow this, but it would be
>>cool if you could specify that an entry in pg_hba.conf could be
>>looked
>>up from /etc/hosts, but not from generic DNS. AFAIK that would
>>eliminate
>>the possibility of spoofing.
>>
>>
>>
>Take a look at 'man /etc/host.conf'.
>
>
>
>

That won't work for per application settings. I think this is a non starter.

I have been thinking more about possible real world use cases for this
facility. I suspect they will be comparatively rare. In cases where you
don't trust DNS you shouldn't use it, and in cases where you do you
probably know the address(es) anyway. If the change is simple it's worth
doing, but it's not a huge leap. The biggest wrinkle will probably be
handling names that map to multiple addresses.

One thing that bothers me slightly is that we would need to look up each
name (at least until we found a match) for each connection. If you had
lots of names in your pg_hba.conf that could be quite a hit. We need to
test this not with one but with a couple of hundred names, maybe, to see
what the hit is like.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> One thing that bothers me slightly is that we would need to look up each
> name (at least until we found a match) for each connection. If you had
> lots of names in your pg_hba.conf that could be quite a hit.

A possible answer to that is to *not* look up the names from
pg_hba.conf, but instead restrict the feature to matching the
reverse-DNS name of the client. This limits the cost to one lookup per
connection instead of N (and it'd be essentially free if you have
log_hostnames turned on, since we already do that lookup in that case).

I'm not sure about the relative usefulness of this compared to the
forward-lookup case, nor whether it's riskier or less risky from a
spoofing point of view. But something to consider.

regards, tom lane

On Tue, Jan 03, 2006 at 12:43:03PM -0500, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > One thing that bothers me slightly is that we would need to look up each
> > name (at least until we found a match) for each connection. If you had
> > lots of names in your pg_hba.conf that could be quite a hit.
> A possible answer to that is to *not* look up the names from
> pg_hba.conf, but instead restrict the feature to matching the
> reverse-DNS name of the client. This limits the cost to one lookup per
> connection instead of N (and it'd be essentially free if you have
> log_hostnames turned on, since we already do that lookup in that case).

> I'm not sure about the relative usefulness of this compared to the
> forward-lookup case, nor whether it's riskier or less risky from a
> spoofing point of view. But something to consider.

I think it's riskier. I have my own PTR records, that I can make be
whatever I wish without any authority verifying that my actions are
proper. Although, most people don't, this is because most people don't
ask for them, or don't know how or where to ask for them. The security
benefit is in the address, not in the name. The convenience is in the
name, and not the address.

I'm not seeing why forward lookups are bad. There are several options
available to controlling this, including configuring /etc/hosts to be
searched first, before DNS, using nsswitch.conf. Another option, is
to use your own DNS server, with its own zone records, such that
/etc/resolv.conf uses 127.1, which will serve my own records, before
doing a recursive lookup over the network.

It's not a big deal. I'd recommend keeping documentation, and inlined
comment warnings all over the place - but if people want to use names,
I'm not seeing the problem. They can already hang themselves, by granting
full access to the Internet, by network mask? :-)

Cheers,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

Tom Lane schrieb:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>>One thing that bothers me slightly is that we would need to look up each
>>name (at least until we found a match) for each connection. If you had
>>lots of names in your pg_hba.conf that could be quite a hit.
>
>
> A possible answer to that is to *not* look up the names from
> pg_hba.conf, but instead restrict the feature to matching the
> reverse-DNS name of the client. This limits the cost to one lookup per
> connection instead of N (and it'd be essentially free if you have
> log_hostnames turned on, since we already do that lookup in that case).

Or alternatively (documented) scan and translate the names
only on restart or sighup. This would limit the overhead
and changes to the confile-scanner only and would
at least enable symbolic names in the config files.
(Of course w/o any wildcards - that would be the drawback)

mark(at)mark(dot)mielke(dot)cc writes:
> On Tue, Jan 03, 2006 at 12:43:03PM -0500, Tom Lane wrote:
>> I'm not sure about the relative usefulness of this compared to the
>> forward-lookup case, nor whether it's riskier or less risky from a
>> spoofing point of view. But something to consider.

> I think it's riskier. I have my own PTR records, that I can make be
> whatever I wish without any authority verifying that my actions are
> proper.

Yeah, that occurred to me after a few moments' thought. We could do one
extra forward lookup to confirm that the reverse-lookup name maps back
to the IP address.

> It's not a big deal.

Depends on how many names you want to put into pg_hba.conf. I don't
offhand see a use-case for very many, but maybe there is one. Even
if there are a lot, they'd not be expensive to look up if there is
a local nameserver that is authoritative for those names ... which
I'd think would be the normal case. The more "outside" names you've
got in pg_hba.conf, the more open you are to spoofing.

regards, tom lane

On Tue, 3 Jan 2006, Tino Wildenhain wrote:

>>> One thing that bothers me slightly is that we would need to look up each
>>> name (at least until we found a match) for each connection. If you had
>>> lots of names in your pg_hba.conf that could be quite a hit.
>>
>> A possible answer to that is to *not* look up the names from
>> pg_hba.conf, but instead restrict the feature to matching the
>> reverse-DNS name of the client. This limits the cost to one lookup per
>> connection instead of N (and it'd be essentially free if you have
>> log_hostnames turned on, since we already do that lookup in that case).
>
> Or alternatively (documented) scan and translate the names
> only on restart or sighup. This would limit the overhead
> and changes to the confile-scanner only and would
> at least enable symbolic names in the config files.
> (Of course w/o any wildcards - that would be the drawback)

That's what I suggested yesterday, but others didn't like it and the
possibility of using /etc/hosts or a name server on the local network to
mitigate speed concerns makes me think they're right.

Jon

--
Jon Jensen
End Point Corporation
http://www.endpoint.com/

Added to TODO:

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

---------------------------------------------------------------------------

Tom Lane wrote:
> mark(at)mark(dot)mielke(dot)cc writes:
> > On Tue, Jan 03, 2006 at 12:43:03PM -0500, Tom Lane wrote:
> >> I'm not sure about the relative usefulness of this compared to the
> >> forward-lookup case, nor whether it's riskier or less risky from a
> >> spoofing point of view. But something to consider.
>
> > I think it's riskier. I have my own PTR records, that I can make be
> > whatever I wish without any authority verifying that my actions are
> > proper.
>
> Yeah, that occurred to me after a few moments' thought. We could do one
> extra forward lookup to confirm that the reverse-lookup name maps back
> to the IP address.
>
> > It's not a big deal.
>
> Depends on how many names you want to put into pg_hba.conf. I don't
> offhand see a use-case for very many, but maybe there is one. Even
> if there are a lot, they'd not be expensive to look up if there is
> a local nameserver that is authoritative for those names ... which
> I'd think would be the normal case. The more "outside" names you've
> got in pg_hba.conf, the more open you are to spoofing.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

>
> Added to TODO:
>
> o 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'm not so sure you need to be paranoid about it. The scenario is, at
startup or HUP, names are looked up and stored as IP addresses. Then hba
works as it is supposed too.

"spoofing" is not really a problem, IMHO, because there should be a fire
wall between PostgreSQL (most services really) and the raw internet, *and*
the admin MUST have control over the authenticity of the name resolver. If
someone is in the position to spoof name resolution, they are probably
also in a position to spoof IP addresses.

While I do see a need for this, but not in a sense that any old name would
be used. I see it more like a data center wide "hosts" file use to
dedicate various IP addresses to various services, i.e. freedb, streetmap,
session, web0, web1, .., webn etc.

What also may be handy in this scenario is that the names must fall within
a range of acceptable addresses.

Range: 192.168.245.1 ... 192.168.254.254

joey (192.168.254.55) -- OK

joey (10.1.1.0) -- Not OK.

This would be useful to declare a range of addresses as having some level
of trust, and specific names within that range as having more (or less).

In this scenario, think of a VPN, "joey" may be a laptop, and while he is
on the VPN he is trusted, and when he is not on the vpn he is not trusted.
This is especially important with regards to cyber security.

Mark Woodward wrote:

>>Added to TODO:
>>
>> o 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'm not so sure you need to be paranoid about it. The scenario is, at
>startup or HUP, names are looked up and stored as IP addresses. Then hba
>works as it is supposed too.
>
>

If you do it like that you destroy the only real use case I can see for
this that has much value, namely to handle cases where the address can
change dynamically.

>"spoofing" is not really a problem, IMHO, because there should be a fire
>wall between PostgreSQL (most services really) and the raw internet, *and*
>the admin MUST have control over the authenticity of the name resolver. If
>someone is in the position to spoof name resolution, they are probably
>also in a position to spoof IP addresses.
>
>While I do see a need for this, but not in a sense that any old name would
>be used. I see it more like a data center wide "hosts" file use to
>dedicate various IP addresses to various services, i.e. freedb, streetmap,
>session, web0, web1, .., webn etc.
>
>What also may be handy in this scenario is that the names must fall within
>a range of acceptable addresses.
>
>Range: 192.168.245.1 ... 192.168.254.254
>
>joey (192.168.254.55) -- OK
>
>joey (10.1.1.0) -- Not OK.
>
>This would be useful to declare a range of addresses as having some level
>of trust, and specific names within that range as having more (or less).
>
>In this scenario, think of a VPN, "joey" may be a laptop, and while he is
>on the VPN he is trusted, and when he is not on the vpn he is not trusted.
>This is especially important with regards to cyber security.
>
>
>

We have address ranges now; are you proposing to have those IN ADDITION
to hostname parameters (as opposed to being an alternative)?

We can over-egg this pudding massively. I suggest we start with a simple
implementation and see what needs it leaves unfilled. I would vote for
allowing a hostname (or list of hostnames?) to replace the address/mask
params, and that at connect time we do a forward lookup trying for a
match with the connecting address. If we get a match then that's the hba
line that applies.

Frankly, any auth mechanism based on the name or address of the client
is insecure. If you have people connecting across possibly insecure
networks you should use SSL with client certificates signed by your own
CA, or a similar approach.

cheers

andrew

Mark Woodward wrote:

>>Mark Woodward wrote:
>>
>>
>>
>>>>Added to TODO:
>>>>
>>>> o 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'm not so sure you need to be paranoid about it. The scenario is, at
>>>startup or HUP, names are looked up and stored as IP addresses. Then hba
>>>works as it is supposed too.
>>>
>>>
>>>
>>>
>>If you do it like that you destroy the only real use case I can see for
>>this that has much value, namely to handle cases where the address can
>>change dynamically.
>>
>>
>
>How "dynamically" are you talking about?
>
>If you are using a DNS server, what is your TTL on the records? A simple
>-HUP once every half hour is more than sufficient. If you are using ssh to
>update the hosts file, adding a simple -HUP tp the script is not a big
>deal.
>
>
>

If I am a road warrior I want to be able to connect, run my dynamic dns
client, and go.

HUPing the postmaster every 30 minutes sounds horrible, and won't work
for what strikes me as the scenario that needs this most. And we surely
aren't going to build TTL logic into postgres.

I repeat - let's do this the simple way.

cheers

andrew

On Mon, Feb 13, 2006 at 10:00:34AM -0500, Andrew Dunstan wrote:
> Mark Woodward wrote:
> >I'm not so sure you need to be paranoid about it. The scenario is, at
> >startup or HUP, names are looked up and stored as IP addresses. Then hba
> >works as it is supposed too.
> If you do it like that you destroy the only real use case I can see for
> this that has much value, namely to handle cases where the address can
> change dynamically.

*nod*

Addresses change, and for a stable PostgreSQL server, this would hopefully
mean that PostgreSQL has uptime across these changes. :-)

> We have address ranges now; are you proposing to have those IN ADDITION
> to hostname parameters (as opposed to being an alternative)?

I like in addition. For example, at work, saying "a.blah.com" and "47.*"
would give me an inch more of comfort, as the organization is large, and
there are numerous channels to having the name changed - but at least if
I know that the name is within 47.*, I know that it isn't somebody in
another partner company connecting directly from their network.

Not bullet proof, but slightly more difficult to manipulate.

> We can over-egg this pudding massively. I suggest we start with a simple
> implementation and see what needs it leaves unfilled. I would vote for
> allowing a hostname (or list of hostnames?) to replace the address/mask
> params, and that at connect time we do a forward lookup trying for a
> match with the connecting address. If we get a match then that's the hba
> line that applies.

Yes.

> Frankly, any auth mechanism based on the name or address of the client
> is insecure. If you have people connecting across possibly insecure
> networks you should use SSL with client certificates signed by your own
> CA, or a similar approach.

Yes.

Cheers,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

> Mark Woodward wrote:
>
>>>Added to TODO:
>>>
>>> o 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'm not so sure you need to be paranoid about it. The scenario is, at
>>startup or HUP, names are looked up and stored as IP addresses. Then hba
>>works as it is supposed too.
>>
>>
>
> If you do it like that you destroy the only real use case I can see for
> this that has much value, namely to handle cases where the address can
> change dynamically.

How "dynamically" are you talking about?

If you are using a DNS server, what is your TTL on the records? A simple
-HUP once every half hour is more than sufficient. If you are using ssh to
update the hosts file, adding a simple -HUP tp the script is not a big
deal.

>
>>"spoofing" is not really a problem, IMHO, because there should be a fire
>>wall between PostgreSQL (most services really) and the raw internet,
>> *and*
>>the admin MUST have control over the authenticity of the name resolver.
>> If
>>someone is in the position to spoof name resolution, they are probably
>>also in a position to spoof IP addresses.
>>
>>While I do see a need for this, but not in a sense that any old name
>> would
>>be used. I see it more like a data center wide "hosts" file use to
>>dedicate various IP addresses to various services, i.e. freedb,
>> streetmap,
>>session, web0, web1, .., webn etc.
>>
>>What also may be handy in this scenario is that the names must fall
>> within
>>a range of acceptable addresses.
>>
>>Range: 192.168.245.1 ... 192.168.254.254
>>
>>joey (192.168.254.55) -- OK
>>
>>joey (10.1.1.0) -- Not OK.
>>
>>This would be useful to declare a range of addresses as having some level
>>of trust, and specific names within that range as having more (or less).
>>
>>In this scenario, think of a VPN, "joey" may be a laptop, and while he is
>>on the VPN he is trusted, and when he is not on the vpn he is not
>> trusted.
>>This is especially important with regards to cyber security.
>>
>>
>>
>
> We have address ranges now; are you proposing to have those IN ADDITION
> to hostname parameters (as opposed to being an alternative)?
>
> We can over-egg this pudding massively. I suggest we start with a simple
> implementation and see what needs it leaves unfilled. I would vote for
> allowing a hostname (or list of hostnames?) to replace the address/mask
> params, and that at connect time we do a forward lookup trying for a
> match with the connecting address. If we get a match then that's the hba
> line that applies.
>
> Frankly, any auth mechanism based on the name or address of the client
> is insecure. If you have people connecting across possibly insecure
> networks you should use SSL with client certificates signed by your own
> CA, or a similar approach.

It isn't so much an auth issue because I'm not assuming a "hacker" so much
as the stream of data that across the network. Within the firewall ==
safe, outside of the firewall can be snooped.

mark(at)mark(dot)mielke(dot)cc writes:
> On Mon, Feb 13, 2006 at 10:00:34AM -0500, Andrew Dunstan wrote:
>> We can over-egg this pudding massively. I suggest we start with a simple
>> implementation and see what needs it leaves unfilled. I would vote for
>> allowing a hostname (or list of hostnames?) to replace the address/mask
>> params, and that at connect time we do a forward lookup trying for a
>> match with the connecting address. If we get a match then that's the hba
>> line that applies.

> Yes.

The original proposal to change this required little more than removing
the AI_NUMERICHOST flag restricting pg_getaddrinfo_all's lookup. I
thought all along that anything more than that was massive overdesign...

regards, tom lane

Mark Woodward wrote:

>>If I am a road warrior I want to be able to connect, run my dynamic dns
>>client, and go.
>>
>>
>>
>In your scenario of working as a road warrior, you are almost
>certainly not going to be able to have a workable DNS host name unless you
>have a raw internet IP address. More than likely you will have an IP
>address (known to your laptop) as a 192 or 10 address.
>

Nonsense. There is a dynamic DNS client that is quite smart enough to
find out and use the gateway address. See: http://ddclient.sourceforge.net/

I'm sure there are others, including some for Windows.

cheers

andrew

>
> If I am a road warrior I want to be able to connect, run my dynamic dns
> client, and go.
>
> HUPing the postmaster every 30 minutes sounds horrible, and won't work
> for what strikes me as the scenario that needs this most. And we surely
> aren't going to build TTL logic into postgres.
>
> I repeat - let's do this the simple way.

While I would certainly agree with you on this one in most cases, DNS is a
sticky and anoying system. Simple solutions typically fail to accomplish
anything. Ask anyone who has implemented DNS based load balancing. And
then, don't trust Windows to act accordingly to TTL values in host
records.

Maybe I'm not sure what you envision, but there are two options, a host
file on the postgresql server, or a DNS server the that postgresql server
interacts with. Your "dynamic dns" system may push a DNS entry up to some
shared DNS server, but you still need to mind the whole TTL issue.

I think what bothers me is that DNS is intended to be a directory for
clients to implement an outward connection by finding an IP address that
is routable. In your scenario of working as a road warrior, you are almost
certainly not going to be able to have a workable DNS host name unless you
have a raw internet IP address. More than likely you will have an IP
address (known to your laptop) as a 192 or 10 address. If you set your
address in some dynamic DNS system, your reported originating IP address
(to PostgreSQL) will most likely be wrong. It will be the public IP
address of your router that PostgreSQL will see.

The more I think about it the uglier it is, I would say an SSH tunnel
would be more secure and less problematic.

> Mark Woodward wrote:
>
>>>If I am a road warrior I want to be able to connect, run my dynamic dns
>>>client, and go.
>>>
>>>
>>>
>>In your scenario of working as a road warrior, you are almost
>>certainly not going to be able to have a workable DNS host name unless
>> you
>>have a raw internet IP address. More than likely you will have an IP
>>address (known to your laptop) as a 192 or 10 address.
>>
>
>
> Nonsense. There is a dynamic DNS client that is quite smart enough to
> find out and use the gateway address. See:
> http://ddclient.sourceforge.net/
>
> I'm sure there are others, including some for Windows.
>

But then, there is another problem, if you don't have a real and true IP
address, if you are on anonymous 192 or 10 net (most likely the case),
then your dynamic DNS entry allows EVERYONE on your network the same
access.

I still say an SSH tunnel with port forwarding is more secure, besides you
can even compress the data stream.

Mark Woodward wrote:

>>Mark Woodward wrote:
>>
>>
>>
>>>>If I am a road warrior I want to be able to connect, run my dynamic dns
>>>>client, and go.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>In your scenario of working as a road warrior, you are almost
>>>certainly not going to be able to have a workable DNS host name unless
>>>you
>>>have a raw internet IP address. More than likely you will have an IP
>>>address (known to your laptop) as a 192 or 10 address.
>>>
>>>
>>>
>>Nonsense. There is a dynamic DNS client that is quite smart enough to
>>find out and use the gateway address. See:
>>http://ddclient.sourceforge.net/
>>
>>I'm sure there are others, including some for Windows.
>>
>>
>>
>
>But then, there is another problem, if you don't have a real and true IP
>address, if you are on anonymous 192 or 10 net (most likely the case),
>then your dynamic DNS entry allows EVERYONE on your network the same
>access.
>
>I still say an SSH tunnel with port forwarding is more secure, besides you
>can even compress the data stream.
>
>
>
>

And then you have to allow shell access. What's wrong with SSL with
client certificates?

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.

(I also agree with a point Jan sometimes makes - that end client s/w
generally should not be talking to the db at all - that's what
middleware is for. Then this whole discussion becomes moot.)

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> 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.

regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> 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.

Well as one of the people that deploys and managees many, many
postgresql installations I can say I have never run into the need to
have dns names and the thought of dns names honestly seems silly. It
will increase overhead and dependencies that I just wouldn't want in my
installations.

Joshua D. Drake

>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

On 2/13/06, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> Well as one of the people that deploys and managees many, many
> postgresql installations I can say I have never run into the need to
> have dns names and the thought of dns names honestly seems silly. It
> will increase overhead and dependencies that I just wouldn't want in my
> installations.

It is not uncommon for an environment that has already suffered
through one forced renumbering to forbid the use of hard set IPs in
application software.

With IPv6 we will just see more and more of that.

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> 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.

> Well as one of the people that deploys and managees many, many
> postgresql installations I can say I have never run into the need to
> have dns names and the thought of dns names honestly seems silly. It
> will increase overhead and dependencies that I just wouldn't want in my
> installations.

If you don't want DNS names, you don't have to use 'em, so arguments of
this sort seem rather irrelevant to me. They would be relevant if we
were talking about expending any great amount of development manpower
... which is why I'd rather see us do something minimal first, and see
if it gets used much.

regards, tom lane