Re: logic check of pg_hba.conf configuration

"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