On Wed, Apr 22, 2015 at 12:07 PM, Simon Slavin <slavins at bigfraud.org> wrote: > On 22 Apr 2015, at 7:18pm, Scott Hess <shess at google.com> wrote: >> The only way SQLite can get to the disk is using the vfs, so if the >> vfs encrypts things, all of the files (main db, temp db, journal, >> everything) will be encrypted. > > Guys. Guys. Guys. My app doesn't have access to any level below > standard file system calls.
Yes. I understand. That's why I suggested you use the SQLite vfs layer. Because at that layer you can intercept calls SQLite makes before they hit the filesystem. If you want to make sure SQLite isn't storing files you don't know about, you can easily enforce that in the vfs. Of course enforcing that may cause SQLite to break if it requires that file for some reason, but I'm assuming that your environment includes test coverage to verify that everything you need continues to work. Assuming such test coverage, you could also use a vfs to enumerate the entire set of files SQLite ever accesses that you'll need to deal with, if you prefer not to have it running in production. > I know a lot about computer security -- problems with drivers and caching > and a ton of stuff I won't discuss here. I asked a question on this list > because I wanted details of what SQLite does. Probably stuff I could get > if I knew SQLite source code well. I just don't have time to read and > understand the right parts of the SQLite source. These are somewhat contradictory claims, so it's hard for me to tell what level you can code things at, but I can tell you that I was able to write a proxy vfs for SQLite in a few hours, including verifying assumptions by browsing SQLite's os_unix.c. One of them is in Chromium's blink repo (Google for chromium_vfs and it's the top hit). -scott
