Jim Mercer writes:
> 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.
Right, but libpq also has no concept of what you call "incoming s
On Sat, Sep 28, 2002 at 03:57:27PM +0200, Michael Paesold wrote:
> Jim Mercer <[EMAIL PROTECTED]> wrote:
> > 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
Jim Mercer <[EMAIL PROTECTED]> wrote:
> 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.
I haven't followed the whole thread, so perhaps I m
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 sup
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 yo
On Thu, 2002-09-26 at 22:42, Tom Lane wrote:
> Jim Mercer <[EMAIL PROTECTED]> writes:
> > as best i can understand, there is no way to get apach/php/pgsql configured
> > (using "PostgreSQL's native access mappings") that would disallow php code
> > in one virtual host from connecting to any databa
On Thu, Sep 26, 2002 at 11:42:44PM -0400, Tom Lane wrote:
> Jim Mercer <[EMAIL PROTECTED]> writes:
> > as best i can understand, there is no way to get apach/php/pgsql configured
> > (using "PostgreSQL's native access mappings") that would disallow php code
> > in one virtual host from connecting
Jim Mercer <[EMAIL PROTECTED]> writes:
> as best i can understand, there is no way to get apach/php/pgsql configured
> (using "PostgreSQL's native access mappings") that would disallow php code
> in one virtual host from connecting to any database on the system.
Betraying my ignorance of PHP here
On Fri, Sep 27, 2002 at 12:06:43PM +1000, Gavin Sherry wrote:
> On Thu, 26 Sep 2002, Jim Mercer wrote:
> > maybe not _totally_ secure, but much moreso than nothing.
>
> I was basically just suggesting that its effect needs to be
> documented. "This needs to be used in conjunction with other forms
On Thu, 26 Sep 2002, Jim Mercer wrote:
> On Fri, Sep 27, 2002 at 11:15:35AM +1000, Gavin Sherry wrote:
> > On Thu, 26 Sep 2002, Jim Mercer wrote:
> > > > I would think so, and IMHO, that's where pgsql access control
> > > > belongs, with pgsql.
> >
> > I totally disagree. It is a language level
On Fri, Sep 27, 2002 at 11:15:35AM +1000, Gavin Sherry wrote:
> On Thu, 26 Sep 2002, Jim Mercer wrote:
> > > I would think so, and IMHO, that's where pgsql access control
> > > belongs, with pgsql.
>
> I totally disagree. It is a language level restriction, not a database
> level one, so why back
On Thu, 26 Sep 2002, Jim Mercer wrote:
>
> the following was sent to the php developer's list, and they came back with:
>
> > > Isn't it generally better (where "better" means more secure,
> > > efficient, and easily maintained) to handle database access
> > > control using PostgreSQL's native
the following was sent to the php developer's list, and they came back with:
> > Isn't it generally better (where "better" means more secure,
> > efficient, and easily maintained) to handle database access
> > control using PostgreSQL's native access mappings?
>
> I would think so, and IMHO, tha
13 matches
Mail list logo
