Simon Slavin wrote: > On 29 Jan 2013, at 8:19am, Scott Hess <[email protected]> wrote: > >> insert into x values ('SQLite is a software library that implements >> a self-contained, serverless, zero-configuration, transactional SQL >> database engine. SQLite is the most widely deployed SQL database engine in >> the world. The source code for SQLite is in the public domain.'); >> -- Repeat that four or five times. >> >> Now, somewhere else, running: >> strings trial.db-journal >> gives me various repetitions of the inserted string present in the journal >> file. This applies even after running 'delete from x;', at which point the >> main database itself will not contain these strings. > > Verified here with version 3.7.12, native with OS X 10.8 installation. > > Can't be helped at all up to closing the connection to the database. > > Once the database connection is closed, still being able to see that text is > a consequence of 'journal_mode = persist' or WAL. I think that this also > can't be helped -- it's inherent in the journal file not being wiped -- but > this is more debatable than the state before the connection is closed. > > The only way to prevent the data being available from a disk-read with > sufficient privileges would be to use "journal_mode = MEMORY". Might be > worth adding a comment to the documentation for the secure_delete PRAGMA.
IMO, both secure_delete and any user-space disk encryption is pointless and wasteful security theatre. What you can do with traces in *filesystem* journal (e.g. data=journal)? What about defragmentation/volume resize/other block relocation? If you use SSD, what you can do with block relocation always used in normal work? (If you use HDD - that can also happen; much more rarely, and usually just before drive dies, but still possibility). If you want to defend against other users, setting proper permissions is sufficient; to improve protection - run all potentially vulnerable services on dedicated accounts, use jail/chroot/containers/VM/etc. If you want real encryption, you use full-disk encryption (like TrueCrypt, LUKS, and their ilk), and encrypt everything at once including any temporary files, swap, hibernation images, etc. If you want defend against other processes running under same user or against root, you lost anyway. They can read anything they need right from memory (e.g. ptrace()), and completely hijack control over your process (keylogger/etc). User-space database encryption and all "safe data erase" tools only provide you with warm feeling of safety without any real security. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
