Phil Frost wrote:
> On Wed, Jul 12, 2006 at 06:09:31PM -0400, Bruce Momjian wrote:
> > Phil Frost wrote:
> > > On Wed, Jul 12, 2006 at 11:37:37AM -0400, Bruce Momjian wrote:
> > > >
> > > > Updated text:
> > > >
> > > > For schemas, allows access to objects contained in the specified
> > > > schema (assuming that the objects' own privilege requirements are
> > > > also met). Essentially this allows the grantee to <quote>look up</>
> > > > objects within the schema. Without this permission, it is still
> > > > possible to see the object names by querying the system tables, but
> > > > they cannot be accessed via SQL.
> > >
> > > No, this still misses the point entirely. See all my examples in this
> > > thread for ways I have accessed objects without usage to their schema
> > > with SQL.
> >
> > OK, well we are not putting a huge paragraph in there. Please suggest
> > updated text.
>
> Well, if you won't explain the whole situation, nor change it, then all
> you can really say is it doesn't really work always. How about this:
>
> For schemas, allows access to objects contained in the specified
> schema. Note that the converse is not true in many cases: revoking
> usage on a schema is not sufficient to prevent access in all cases.
> There is precedent for new ways to bypass this check being added in
> future releases. It would be unwise to give this privilege much
> security value.
Updated text:
For schemas, allows access to objects contained in the specified schema (assuming that the objects' own
privilegerequirements are also met). Essentially this allows the grantee to <quote>look up</> objects within
theschema. Without this permission, it is still possible to see the object names, e.g. by querying the system
tables, so this is not a completely secure way to prevent object access.
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +