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. 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, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature
