On 2011-07-08, at 12:20 PM, Mingming Cao wrote: > On Fri, 2011-07-08 at 03:09 +0300, Amir Goldstein wrote: >> I realized that there is a basic flaw in the concept of deferred-secure-delete. >> From a security point of view, after a crash during a secure-delete, >> if the file is not there, all its data should have been wiped. >> Orphan cleanup on the next mount may be done on a system that >> doesn't respect secure delete. >> So for real security, the unlink/truncate command cannot return before >> all data is wiped. > > I agree. I think the user who expect secure delete will be expecting the > data being completely wiped off from disk, instead of wondering when the > OS/fs will really get rid of the data on the hidden inode by background > thread. Secure delete should be synchronous. I'm not going to argue further for async secure delete, but just wanted to point out that userspace can determine when the "shred" is safely done on disk (or any other operation for that matter) by doing a sync afterward. It wouldn't have to "wonder" about anything. My original proposal for using the delete thread included having sync() block until all of the background secure unlink/overwrite operations were finished. That would allow deleting many files at one time, and then sending all of the requests to the disk more efficiently. I am just imagining some Enron accountant sweating for hours as his sync secure-delete is running at 50-100 files/sec (seek limit if there are 1 or 2 seeks/file) on a filesystem with 1M files in it, instead of being able to delete 50000 files/sec asynchronously and wait a few minutes at the end as the sync completes. ;-) A better solution is to just encrypt the data with a per-inode key and then just overwrite the inode securely when it is unlinked, so when the key is erased the data is unrecoverable. I imagine that ecryptfs or similar might do something like that (I don't know much about it, honestly). Note that this should probably get an EXT4_FEATURE_COMPAT_SECDEL flag, so e2fsck knows to also wipe secure-delete files when they are unlinked due to inode corruption, or similar. This reminds me I also have an e2fsck patch that we've been carrying for a few years for shared block handling that allows e2fsck to optionally move inodes to lost+found, delete them, or wipe the shared blocks option. This is necessary to avoid data leakage between users in case there is some corruption that links one user's inode to another user's blocks. I'll send that in another email. Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
