Re: lastval exposes information that currval does not

On 7/9/2006 8:32 AM, Martijn van Oosterhout wrote:

> On Sat, Jul 08, 2006 at 05:47:33PM -0400, Jim Nasby wrote:
>> On Jul 6, 2006, at 11:02 AM, Phil Frost wrote:
>> >I hope the above example is strong enough to elicit a comment from a
>> >qualified developer. If it is not, consider that stored procedures
>> >contain prepared statements, and many client applications cache  
>> >prepared
>> >statements as well. Thus, revoking usage on a schema is about as  
>> >good as
>> >nothing until all sessions have ended. It also means that any function
>> >which operates with OIDs can potentially bypass the schema usage  
>> >check.
>> 
>> The docs probably should elaborate that once something's been looked  
>> up you no longer need permissions on the schema it resides in.
> 
> I'm not sure this is really unexpected behaviour. On UNIX it is clearly
> defined that file permissions are checked only on open. Once you've
> opened it, changing permissions on the file won't affect you. If
> someone passes you a read/write descriptor to a file, you can
> read/write it even if you didn't have permissions to open the
> file/socket/whatever yourself.

This isn't the case and I do agree with Phil on this. The fact that 
another "security definer" function did access an object during the 
session should not give the user the ability to access it in the manner 
shown in his example. lastval() without arguments should not remember 
the sequence by its oid only, but also remember the sequences schema and 
to a proper ACL check on that as well.

Just think of it if SELECT without a FROM clause would automatically 
assume the same rangetable as the last SELECT in the session. If that 
were the case, would you guy's defend the position that "SELECT *" then 
should spit out the full content of the last table accessed by the 
security definer function just called, even if the user doesn't have 
schema permission? I doubt!


Jan

> 
> I'm not sure it makes sense to be able to revoke someone's permissions
> on an object they've already accessed. From a transactional point of
> view, the revoke should at the very least not affect transactions
> started prior to the revokation. Some things are shared across an
> entire session, and the rule extends to them. Is this a bug? Maybe, but
> it is debatable.
> 
> Have a nice day,


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #