Re: lastval exposes information that currval does not - Mailing list pgsql-hackers

OK, text again updated:
      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.     Also, after revoking this permission, existing backends might have      statements that have previously
performedthis lookup, so this is not      a completely secure way to prevent object access.
 


---------------------------------------------------------------------------

Phil Frost wrote:
> 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

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +