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" <[EMAIL PROTECTED]> To: "Rod Taylor" <[EMAIL PROTECTED]> Cc: "Hackers List" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org