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

Updated text:
      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 by querying the system tables,
but     they cannot be accessed via SQL.
 


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

Jan Wieck wrote:
> 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 #
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

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