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 case! 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 match