On Sun, Jul 09, 2006 at 11:24:38AM -0400, Phil Frost wrote: > On UNIX it is also clearly defined that if one does not have execute > permissions on a directory, one can not open files within it by *any* > *means*. There are no procedures that bypass this by taking an inode > number directly.
Well, not entirely true. If a file exists in multiple directories, you can open it as long as any of the directories are currently accessable to you (which is not the same as being accessable if you logged in again). However, the issue has been confused here by two completely different examples. In one case you prepare a statement and then execute it later which succeeds even though if you reprepared the statement it would fail. This is no different from the UNIX case where having an open file survives removing of permissions and even deletion. > It is generally understood in the UNIX commuinity that adding a function > in a new version that grants capabilities that were previously > unavailable is an obvious security bug. In this case you're referring to the lastval() issue. That case is debatable I guess... You're suggesting it return a permission error instead. It's a little odd, though it think it's defensible position though. IMO you should simply drop the lastval() function altogether, since I don't think it's really that useful in exchange for the problems it creates. > If it doesn't make sense to be able to revoke permissions on objects > already accessed, why is this the behaviour of everything except the > schema usage check? Does your definition of "already accessed" include > "accessed in a 'security definer' procedure intended to prevent the > caller from accessing an object directly"? Well, that's a good question. At a guess it's because the select/update/delete permissions are a property of the table, whereas the schema is not. The table is a member of the schema. All that suggests is that you should be revoking the permissions on the table itself, rather than on the schema. In the same vein, when reloading the pg_hba.conf, the database doesn't immediatly disconnect all users who would be disallowed by the new rules. > Given that there are already several ways to bypass the check for usage > on a schema, and the developers seem to not be bothered at all by adding > more, of what security use is the schema usage privilege? Several other ways? If there were a case where a user who has never had access to a schema could access something in it, that would be an issue. But arguing about when a revoke should take effect is a completely different issue. IME the developers are extremely interested in security issues. > At a minimum, I'd like to see the documentation updated to document the > weakness of the usage privilege, and how to prevent these exploits. I'll > write the patch if there is agreement. Ideally, I'd like to see the > usage privilege changed to something more consistent and useful. I think it might be helpful for the documentation to state that USAGE controls whether people can lookup objects within a schema and that removing USAGE doesn't block access to the objects themselves, only that they may not be referred to by name. To do that you need to revoke permissions on the objects themselves. I'm not a core developer though, so my opinions aren't really that relevent. Do other database systems work the way you expect? Have a nice day, -- Martijn van Oosterhout <firstname.lastname@example.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
Description: Digital signature