Tom Lane writes:
> Peter Eisentraut <[EMAIL PROTECTED]> 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 checke
sentraut" <[EMAIL PROTECTED]>; "Rod Taylor" <[EMAIL PROTECTED]>;
"Hackers List" <[EMAIL PROTECTED]>
Sent: Sunday, April 14, 2002 10:38 PM
Subject: Re: [HACKERS] Security Issue..
> Tom Lane wrote:
> > But having said that, I do not foresee being
Tom Lane wrote:
> 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
Peter Eisentraut <[EMAIL PROTECTED]> 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.
gt;
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 shou
t; <[EMAIL PROTECTED]>
To: "Rod Taylor" <[EMAIL PROTECTED]>
Cc: "Hackers List" <[EMAIL PROTECTED]>
Sent: Sunday, April 14, 2002 9:33 PM
Subject: Re: [HACKERS] Security Issue..
> Rod Taylor wrote:
> > I'm running into a minor issue with securit
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 t
Rod Taylor wrote:
> I'm running into a minor issue with security in regards to users being
> able to see constructs that they have no access too.
>
> The solution? Information_Schema coupled with no direct access to
> pg_catalog. Internals can use pg_catalog, possibly super users, but
> regular
I'm running into a minor issue with security in regards to users being
able to see constructs that they have no access too.
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