Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium
New issue 781 by Scott.Hess: ForbidActions() in database_utils.cc should be a whitelist, not a blacklist.
http://code.google.com/p/gears/issues/detail?id=781 When making SQLite changes, such as importing new revisions, you have to be careful not to expose unexpected APIs. Right now ForbidActions() blocks certain actions for security reasons (PRAGMA). Other actions are blocked by using compile-time changes (VACUUM, fts2_tokenizer, ATTACH). A much stronger approach would be to have a way to only *allow* specific actions. So it's not so much that PRAGMA is disallowed, it's that PRAGMA is not allowed. This change would make us more resilient to future SQLite changes. fts2_tokenizer() wouldn't be available unless someone explicitly made it available. Some things, such as VACUUM, should optionally allow some sort of assertion to make sure that changes to the compile-time system don't change something like this. This would have to be optional, though, because some systems (such as Android) may want to use a different SQLite build than we use for space reasons. I'm not entirely certain what the performance implications of this are. Simply having the authorizer in the loop is obviously not optimally performant, but given our lack of cached statements, that's probably not a huge issue. But any implementation should strive to not use techniques which require dozens of additional function calls. A hash_map might be reasonable, but since the whitelist will be static at compile-time, something better might be available. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
