>> running version 7.0
>7.0? Not even 7.0.something? You really ought to update.
Havn't seen anyting critical requiring an upgrade... 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)
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. (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.
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.
I do appreciate the response Tom.
Dave