Re: [HACKERS] Checking pg_hba.conf in the child process
On Sat, Feb 25, 2012 at 00:45, Tom Lane wrote: > Alvaro Herrera 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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Checking pg_hba.conf in the child process
Alvaro Herrera 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Checking pg_hba.conf in the child process
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 http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Checking pg_hba.conf in the child process
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 The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
