Re: logic check of pg_hba.conf configuration - Mailing list pgsql-admin
From | Tom Lane |
---|---|
Subject | Re: logic check of pg_hba.conf configuration |
Date | |
Msg-id | 6045.1015812465@sss.pgh.pa.us Whole thread Raw |
In response to | logic check of pg_hba.conf configuration ("Dave" <dave@hawk-systems.com>) |
Responses |
Re: logic check of pg_hba.conf configuration
("Dave" <dave@hawk-systems.com>)
|
List | 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 by date: