Checking pg_hba.conf in the child process

In looking over our authentication code, I noticed that we create the
child process before we check any of the pg_hba.conf file. Now, I
realize we can't do authentication in the postmaster because of possible
delay, and checking the user name and database name filters is just work
that is better done in the child, but checking the IP address might
prevent unauthorized clients from causing excessive process creation on
the server. I know we have listen_addresses, but that defaults to "*"
on the click-through installers, and not everybody knows how to set up a
firewall.

Anyway, I just wanted to mention it in case there was something to be
done here.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Excerpts from Bruce Momjian's message of vie feb 24 19:19:10 -0300 2012:
> In looking over our authentication code, I noticed that we create the
> child process before we check any of the pg_hba.conf file. Now, I
> realize we can't do authentication in the postmaster because of possible
> delay, and checking the user name and database name filters is just work
> that is better done in the child, but checking the IP address might
> prevent unauthorized clients from causing excessive process creation on
> the server. I know we have listen_addresses, but that defaults to "*"
> on the click-through installers, and not everybody knows how to set up a
> firewall.

Hm, one thing to keep in mind is that we allow hostnames there. It'd be
a pain to have postmaster hang while resolving names.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Fri, Feb 24, 2012 at 07:27:06PM -0300, Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of vie feb 24 19:19:10 -0300 2012:
> > In looking over our authentication code, I noticed that we create the
> > child process before we check any of the pg_hba.conf file. Now, I
> > realize we can't do authentication in the postmaster because of possible
> > delay, and checking the user name and database name filters is just work
> > that is better done in the child, but checking the IP address might
> > prevent unauthorized clients from causing excessive process creation on
> > the server. I know we have listen_addresses, but that defaults to "*"
> > on the click-through installers, and not everybody knows how to set up a
> > firewall.
>
> Hm, one thing to keep in mind is that we allow hostnames there. It'd be
> a pain to have postmaster hang while resolving names.

Yes, we would still need to recheck the filter in the child because of
username/dbname limits, but your point is very valid --- any use of
hostnames in pg_hba.conf would prevent us from doing IP checks.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Bruce Momjian's message of vie feb 24 19:19:10 -0300 2012:
>> In looking over our authentication code, I noticed that we create the
>> child process before we check any of the pg_hba.conf file. Now, I
>> realize we can't do authentication in the postmaster because of possible
>> delay, and checking the user name and database name filters is just work
>> that is better done in the child, but checking the IP address might
>> prevent unauthorized clients from causing excessive process creation on
>> the server. I know we have listen_addresses, but that defaults to "*"
>> on the click-through installers, and not everybody knows how to set up a
>> firewall.

> Hm, one thing to keep in mind is that we allow hostnames there. It'd be
> a pain to have postmaster hang while resolving names.

Yes. This cure would be a lot worse than the disease. Bruce ought to
remember that we intentionally moved all that logic *out* of the
postmaster process, years ago, precisely because it was too hard to
ensure that the postmaster wouldn't block and thus create DOS conditions
of another sort.

regards, tom lane

On Sat, Feb 25, 2012 at 00:45, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Excerpts from Bruce Momjian's message of vie feb 24 19:19:10 -0300 2012:
>>> In looking over our authentication code, I noticed that we create the
>>> child process before we check any of the pg_hba.conf file.  Now, I
>>> realize we can't do authentication in the postmaster because of possible
>>> delay, and checking the user name and database name filters is just work
>>> that is better done in the child, but checking the IP address might
>>> prevent unauthorized clients from causing excessive process creation on
>>> the server.  I know we have listen_addresses, but that defaults to "*"
>>> on the click-through installers, and not everybody knows how to set up a
>>> firewall.
>
>> Hm, one thing to keep in mind is that we allow hostnames there.  It'd be
>> a pain to have postmaster hang while resolving names.
>
> Yes.  This cure would be a lot worse than the disease.  Bruce ought to
> remember that we intentionally moved all that logic *out* of the
> postmaster process, years ago, precisely because it was too hard to
> ensure that the postmaster wouldn't block and thus create DOS conditions
> of another sort.

As long as the block would only look at the IP it would also be
trivial - and more efficient - to do the same blocking in the
firewall, either local host firewall rules or the network firewall
depending on deployment...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/