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
