Re: Security Issue.. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Security Issue..
Date
Msg-id 6169.1018838011@sss.pgh.pa.us
Whole thread Raw
In response to Re: Security Issue..  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Security Issue..  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Security Issue..  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> For instance, if you create a view
>     CREATE VIEW bar AS SELECT * FROM foo;
> then the statement
>     SELECT * FROM bar;
> needs privileges to read "foo".

This works just fine, thank you: the privileges are checked against the
owner of the view.

> The privileges would need to be changed
> to be checked at view creation time.

That would be broken; privileges are and must be checked at query
time not view creation time.


But having said that, I do not foresee being able to replace direct
pg_catalog access with INFORMATION_SCHEMA views anytime soon.  There
are too many clients out there that are used to doing it that way.

Moreover, pg_dump will never be able to work off INFORMATION_SCHEMA,
because it needs to get at Postgres-specific information that will
not be available from a spec-compliant set of views.  I'm fairly
dubious about converting psql, even.

Rod's welcome to work on developing a set of spec-compliant
INFORMATION_SCHEMA views ... and maybe he can even turn off public
read access to pg_catalog in his own installation ... but he should
not expect us to accept a patch that makes that the default anytime
in the foreseeable future.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: regexp character class locale awareness patch
Next
From: "Christopher Kings-Lynne"
Date:
Subject: That CREATE OPERATOR CLASS patch