pg_hba.conf settings (was: Postgres not starting at boot...)

>> running version 7.0
>7.0?  Not even 7.0.something?  You really ought to update.

Havn't seen anyting critical requiring an upgrade in the last 6 months...  call
it laziness or not wanting to fix something that isn't broke and causing
problems.  This security issue may end up being that reason though.

>But I digress...
ditto...

<clip to everything else>

ok, let me step back and come at it this way (at the risk of a RTFM which has
been done extensively).  I sent my understanding of the pg_hba.conf entries to
the admin list, and just can't seem to get the correct mix of permissions to
accomplish the level of permissions we require.

Authentication/Security Goals

Assuming I want to allow postgres to start up unattended at startup (FreeBSD) so
local machine needs to be trusted or the startup script chokes waiting for a
password. (recent failure of boot scripts was as a result of us changing
everything to password).  Startup does an su to user pgsql to run the pg_ctl to
start/stop the database on reboot. Can I trust a single user (like pgsql) for
this purpose?

Assuming that I have multiple users, all with FTP access only (no shell
accounts).  I do have some of these users with postgres databases, and am
managing postgres users with the same ftp username/password, and restricting
databases within postgres etc...   Requests for these databases will be via PHP
or Perl scripts and they will be running as the web server (so user
nobody/apache whatever).   I want to require these users to place their postgres
username and password in their PHP/Perl script in order to access ANY database,
and when they provide those, they should only be able to access databases that
that user has permissions to access from within postgres...  no automatic or
passwordless access.   Easy to secure the username and passwords for accessing
the database with unix file permissions and keeping them out of the web root.

Assuming I do have some shell users on this box, but they should only have to
access their own scripts aside from admin accounts which will need access to all
databases.

Assuming I need access to all databases from the 123.45.678.1 server...  can
provide a username and password since they are scripted items so it doesn't
necessarily HAVE to be trust'ed, we can secure the scripts appropriately
(probably better than trusting anything anyway).

This server is the ONLY server currently that needs to access any database from
outside the postgres server itself.  If we add others in the future it would be
to specific databases and we would probably use the same password as we would
with the 123.45.678.1 server since these would be exceptions to the rule.

The permissions just don't seem to be designed around that sort of
flexibility/restrictions, or at least not the way I am looking at it.  Perhaps
it s a "forest for the trees" type of thing.

Dave