On Wed, Jul 19, 2006 at 02:42:49PM -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, e.g. by querying the system tables,
>        so this is not a completely secure way to prevent object access.

I think you are not understanding the nature of the problem I have
described. It is just not the names that can be accessed in the absence
of usage on a schema, it is *the content of the relations*. It is
obvious to anyone who has ever looked in pg_* that metadata is not
hidden by any amount of permission twiddling with grant and revoke. This
isn't great from a security standpoint, but at least it's documented and
expected, so one can design around it.

However, the usage on schema privilege has undocumented, unexpected
behavior. One would think from the documentation and from
experimentation that one can not exercise any privileges on an object
(excepting what can be done through the system catalogs) without having
usage on the schema that contains it. However, this is not always the

If you look at my previous posts, I have repeatedly demonstrated ways to
access objects (not just the names or metadata, but the _full_
_contents_) contained in a schema to which one does not have the 'usage'
privilege. The developers must consider this a "feature", because none
have acknowledged it as a security bug. This being the case, it is
important that people be advised that the schema usage privilege does
not always control access to contained objects, and that the ways which
it can be bypassed are perhaps not numerous, but definitely subtle, and
thus likely to escape security audits and later be discovered by an
attacker. It should be known that the PostgreSQL developers have
recently added a function lastval() which newly exposes such a way to
bypass the check, and that this has not been officially acknowledged as
a security flaw.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to