Quoth Scott Hess <sh...@google.com>, on 2010-10-12 10:33:54 -0700: > Since the tokenizer-registration code accepts an encoded pointer to a > vtable, it probably should be considered unsafe to expose to users. > > For Gears and Chrome, where SQLite is exposed to web developers, we > did manual tokenizer registration and disabled the SQL-based > registration code. This can be done using authorizers.
Yes, it can. However, it seems like surprising behavior that opening an arbitrary database and writing to it can corrupt the host program (via a specially-crafted trigger) unless you apply a restrictive authorizer first. In particular, this makes writing to arbitrary databases from the SQLite shell unsafe without a lot of rigamarole, since I know of no way to even set an authorizer in that case; one would have to remember to select and examine all the triggers first. It may be that a better approach would be to be more restrictive about triggers by default, then allow the user to reset a separate "trigger authorizer" to something more permissive if it is desired. I think this would not break existing code so long as it did not restrict new functions by default, since calling these particular unsafe functions in triggers (I think only FTS3 registration falls into this category so far?) is already mostly useless. In fact, I think my thoughts on this are now well-formed enough to submit an actual ticket to this effect. Since the bug report page at http://www.sqlite.org/src/wiki?name=Bug+Reports says that posting to the list is the correct way to do this, please consider the above such a request. (I will look into a patch if I have time, though this is moderately unlikely.) Additional comments are naturally welcome. ---> Drake Wilson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
