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 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.                                  #
> #================================================== [EMAIL PROTECTED] #
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to