Skip site navigation (1) Skip section navigation (2)

Re: hacker help: PHP-4.2.3 patch to allow restriction of database access

From: Jim Mercer <jim(at)reptiles(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>,Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
Subject: Re: hacker help: PHP-4.2.3 patch to allow restriction of database access
Date: 2002-09-28 13:23:34
Message-ID: 20020928132334.GA9014@reptiles.org (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

cool!

> > 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        jim(at)reptiles(dot)org         +1 416 410-5633 ]
[          I want to live forever, or die trying.            ]

In response to

Responses

pgsql-hackers by date

Next:From: Michael PaesoldDate: 2002-09-28 13:57:27
Subject: Re: hacker help: PHP-4.2.3 patch to allow restriction of database access
Previous:From: Peter EisentrautDate: 2002-09-28 11:10:53
Subject: Re: AIX compilation problems (was Re: Proposal ...)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group