On Sat, Sep 28, 2002 at 03:57:27PM +0200, Michael Paesold wrote:
> Jim Mercer <jim(at)reptiles(dot)org> wrote:
> > as it currently stands, virtual hosts can trample all over other
> > and with the nature of a single uid for all apache/php/libpq proceses,
> > they are generally doing it with the same pgsql user.
> I haven't followed the whole thread, so perhaps I missed something. But why
> not just use password authentication to the database with a different user
> for each database? Ok, one has to store the plain-text passwords in the php
> files. You have to protect your users from reading each others files anyway;
> this can be done.
that can be done, but plain-text passwords are not good. also, it doesn't
stop users from cruising other databases for unprotected data.
my patch will control that, at least in the context of apach/php/libpq.
> At least you can set up different users per database, so that it doesn't
> matter if the proposed restriction setting is by database or by user.
most of the databases have one user, that of the httpd process.
from what i've seen, this is fairly standard with virtual hosting.
until we have per-database users, generally what you end up doing is creating
a per-database user/password table, and then write applications that control
things based on that table, as opposed to the system table. this means that
all of the tables in a database need to be read/write by one central user.
i've always found this hokey, but necessary.
the up-coming per-table userlist will help this alot.
[ Jim Mercer jim(at)reptiles(dot)org +1 416 410-5633 ]
[ I want to live forever, or die trying. ]
In response to
pgsql-hackers by date
|Next:||From: Justin Clift||Date: 2002-09-28 14:43:12|
|Subject: Re: How to REINDEX in high volume environments?|
|Previous:||From: Michael Paesold||Date: 2002-09-28 13:57:27|
|Subject: Re: hacker help: PHP-4.2.3 patch to allow restriction of database access|