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

From Phil Frost
Subject Re: lastval exposes information that currval does not
Date
Msg-id 20060706002502.GA7529@unununium.org
Whole thread Raw
In response to Re: lastval exposes information that currval does not  (Chris Campbell <chris@bignerdranch.com>)
Responses Re: lastval exposes information that currval does not
List pgsql-hackers
On Wed, Jul 05, 2006 at 08:06:12PM -0400, Chris Campbell wrote:
> On Jul 5, 2006, at 14:51, Phil Frost wrote:
> 
> >test=# create function bump() returns bigint language sql security  
> >definer as $$ select nextval('private.seq'); $$;
> 
> SECURITY DEFINER means that the function runs with the permissions of  
> the role used to create the function (ran the CREATE FUNCTION  
> command). Due to your # prompt, I'm guessing that you were a  
> superuser when you ran this command. Thus, bump() will be run with  
> the superuser's permissions.
> 
> The superuser most definitely has permissions to access private.seq.
> 
> This has nothing to do with schema security or lastval() versus  
> currval().
> 
> Check out the CREATE FUNCTION documentation:
> 
>    http://www.postgresql.org/docs/8.1/interactive/sql- 
> createfunction.html

I am well aware of what security definer means. The significant part of
this example is that lastval() will allow the caller to see the value of
a sequence where currval('seq') will not. This means that things which
might have been forbidden in 8.0 are now accessible in 8.1.

It also means that revoking usage on a schema is not sufficient to
prevent a user from accessing things within that schema, a property that
makes me quite uncomfortable.


pgsql-hackers by date:

Previous
From: Chris Campbell
Date:
Subject: Re: lastval exposes information that currval does not
Next
From: "Joshua D. Drake"
Date:
Subject: Re: lastval exposes information that currval does not