Re: logic check of pg_hba.conf configuration
От | Tom Lane |
---|---|
Тема | Re: logic check of pg_hba.conf configuration |
Дата | |
Msg-id | 6045.1015812465@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | logic check of pg_hba.conf configuration ("Dave" <dave@hawk-systems.com>) |
Ответы |
Re: logic check of pg_hba.conf configuration
("Dave" <dave@hawk-systems.com>)
|
Список | pgsql-admin |
"Dave" <dave@hawk-systems.com> writes: > running version 7.0 7.0? Not even 7.0.something? You really ought to update. But I digress... > current pg_hba.conf contains// > local all trust > host sameuser 127.0.0.1 255.255.255.255 password This strikes me as very wrong. Line 1 says that you will trust any process running on the local host, and then in line 2 you want to be much more paranoid simply because the connection is loopback TCP and not Unix-socket transport. Anyone who can get at a Perl script running on your box can surely have his choice of transport methods from there to the database; so I don't see the percentage in closing the door to 127.0.0.1 while leaving the Unix-socket door wide open. Also, if line 2 is intended for scripted access, password authentication seems like a poor choice. Where's the script going to get the password? Surely it's a bad idea to encourage people to store passwords directly in PHP scripts ... yet that's exactly what you'll get with this. Depending on how your scripting support is set up, you might consider local all password host sameuser 127.0.0.1 255.255.255.255 ident This (assuming you are running a trustworthy ident daemon) would allow scripts to connect without a password as long as they are running under the Unix userid matching their database name and database user id; so the security issue moves away from PG and into whatever you use to authenticate the right to create/run a script. Local admins would have to give a password, which is annoying but at least not a security hole. If you were to update to 7.1 or 7.2 you would have more flexibility; in particular it'd be possible to shield the Unix-socket file with filesystem permissions, which would be a much nicer way of restricting admin access than passwords. (You can't realistically run pg_dump from a cron task if admin access requires passwords :-(.) > host all 123.45.678.1 255.255.255.255 trust Okay as long as you really really trust all users on that machine. You might also want to think about whether your network is firewalled sufficiently that an attacker could not inject packets claiming to be from that machine. > host all 0.0.0.0 0.0.0.0 reject You realize of course that this is redundant (dropping off the end of pg_hba.conf is an implicit reject). Okay as documentation though. regards, tom lane
В списке pgsql-admin по дате отправления: