On Wed, 22 Apr 2015 16:56:07 +0100 Simon Slavin <slavins at bigfraud.org> wrote:
> You have made me realise, however, that a nice attack against > encrypted SQLite databases might be to crash a SQLite application > while it's processing and examine any journal files, shared memory > file and temporary index files. It might be interesting to review > the various encryption systems widely available for SQLite and figure > out which of them would be vulnerable to such an attack. Encryption found its way into DBMS featuredom about 10 years ago, I guess. I've always thought it was patently stupid. A DBMSs job is store data. Encryption probably should be done in the application. Failing that, whole-filesystem encryption solves the problem in a general way. For SQLite, an encrypted loopback filesystem would solve you problem neatly, except for that "no virtual filesystem" stipulation. Coming back to the problem at hand, Scott Hess suggested that you modify the SQLite VFS to trap all calls to the underlying open(2). In that way ISTM you could add each opened filename to a list processed by a function whose address is passed to atexit(3). Assuming the task terminates nomally (unsignalled) all registered files would be deleted by that function. If signals also need to be dealt with (IIUC they do not) then I would fork the process that uses SQLite and arrange for the parent to delete the files when the child terminates. What I like about the VFS idea is that it's minimally dependent on SQLite particulars. However the code changes in the future, its relationship to the VFS will be quite stable. You don't need to know how many OS files are opened, or by what name. Just trap and record each one. HTH. --jkl
