Yeah, I was planning on blocking queries to pg_catalog for all cases.
Make it so that it can never be done by any user directly. It would
have to be done in the parser before the view was evaluated, and no
user created views would be allowed to access pg_catalog.
The spec describes the definition schema as accessable only from the
information schema.
Long term goal of course. It would take a few releases to ensure that
everything was setup to be done like that.
--
Rod Taylor
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
how restful it is to watch the cursor blink. Close your eyes. The
opinions stated above are yours. You cannot imagine why you ever felt
otherwise.
----- Original Message -----
From: "Peter Eisentraut" <peter_e@gmx.net>
To: "Rod Taylor" <rbt@zort.ca>
Cc: "Hackers List" <pgsql-hackers@postgresql.org>
Sent: Sunday, April 14, 2002 9:45 PM
Subject: Re: [HACKERS] Security Issue..
> Rod Taylor writes:
>
> > The solution? Information_Schema coupled with no direct access to
> > pg_catalog. Internals can use pg_catalog, possibly super users,
but
> > regular users shouldn't be able to do any reads / writes to it
> > directly -- as per spec with definition_schema.
>
> The catch on this is that privileges on views don't work quite
perfectly
> yet. 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". The privileges would need to be
changed
> to be checked at view creation time.
>
> --
> Peter Eisentraut peter_e@gmx.net
>
