On Sat, Sep 28, 2002 at 01:08:36PM +0200, Peter Eisentraut wrote:
> Jim Mercer writes:
> > ideally, i'd like to have users-per-database, as opposed to the global
> > model we have now.
> That's in the works.  Some form of this will be in 7.3.


> > if we are willing to modify libpq to support a "white-list", then what you
> > are suggesting is quite possible.
> How would you store such a list and prevent users from simply unsetting
> it?

the list is something determined by the client, effectively, in this scenario.

basically, i'm just looking at a libpq function that will take a white-list,
and only allow connections through PQconnect() based on that list.

the reasoning for this is that postmaster has no ability to differentiate
between incoming sessions, and as such, storing the list in the server makes
no sense, the server won't know how to apply the list.

in the scenario i'm working with, apache/php/libpq are safe from change by
the users.  apache has the ability to pass values through php to libpq which
the user cannot change.

so apache would tell libpq what tables _this_ instance of apache/php/libpq
can access.

simply using environment variables is not good enough, as the user can
change their values in their php scripts.

> > i suspect the php-dev people are unhappy with my patch because it is including
> > logic (ie. parsing the white-list) which they don't think php should be
> > responsible for.
> From my reading of the discussion, I think they have not understood that
> the PostgreSQL server has no way to distinguish different virtual host
> identities.  I think your feature is quite reasonable, if you list users
> instead of databases.

well, for my purposes, it is _databases_ i'm more concerned about.  each
virtual host should be restricted to specific databases. this way each user
is entitled to mess up their own world, but not mess with other people's.

as it currently stands, virtual hosts can trample all over other databases,
and with the nature of a single uid for all apache/php/libpq proceses,
they are generally doing it with the same pgsql user.

vigilience over the user-level permissions is not something i trust the users
to do.  8^(

[ Jim Mercer        [EMAIL PROTECTED]         +1 416 410-5633 ]
[          I want to live forever, or die trying.            ]

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


Reply via email to