On 7 Sep 2017, at 5:34pm, Jens Alfke <j...@mooseyard.com> wrote:
> On Sep 7, 2017, at 9:31 AM, Simon Slavin <slav...@bigfraud.org> wrote: > >> Either way, you should be able to do something like this with UPDATE and >> DELETE TRIGGERs which causes the new command to fail. They could do this by >> violating a constraint, or by division by zero, or referring to a table >> which didn’t exist. Those things should cause SQLite to crash or return a >> failure code rather than successfully replacing the original record. > > That can be bypassed by editing the raw file data, without going through > SQLite, so I'm assuming it wouldn't be secure enough for the OP. In that case any solution implemented entirely within SQLite is insecure because the admins can simply replace the entire file. Or use a hex editor to replace the checksum values. In cases like this the security the OP is asking for has to be built in at the OS level. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
