On 08/11/2014 04:27 PM, Chris Murphy wrote: > > On Aug 10, 2014, at 8:53 PM, Austin S Hemmelgarn > <ahferro...@gmail.com> wrote: > >> >> Another thing that isn't listed there, that I would personally >> love to see is support for secure file deletion. To be truly >> secure though, this would need to hook into the COW logic so that >> files marked for secure deletion can't be reflinked (maybe make >> the automatically NOCOW instead, and don't allow snapshots?), and >> when they get written to, the blocks that get COW'ed have the old >> block overwritten. > > If the file is reflinked or snapshot, then it can it be secure > deleted? Because what does it mean to secure delete a file when > there's a completely independent file pointing to the same physical > blocks? What if someone else owns that independent file? Does the > reflink copy get rm'd as well? Or does the file remain, but its > blocks are zero'd/corrupted? The semantics that I would expect would be that the extents can't be reflinked, and when snapshotted the whole file gets COW'ed, and then inherits the secure deletion flag, possibly with another flag saying that the user can't disable the secure deletion flag. > > For SSDs, whether it's an overwrite or an FITRIM ioctl it's an open > question when the data is actually irretrievable. It may be > seconds, but could be much longer (hours?) so I'm not sure if it's > useful. On HDD's using SMR it's not necessarily a given an > overwrite will work there either. By secure deletion, I don't mean make the data absolutely unrecoverable by any means, I mean make it functionally impractical for someone without low-level access to and/or extensive knowledge of the hardware to recover the data; that is, more secure than simply unlinking the file, but obviously less than (for example) the application of thermite to the disk platters. I'm talking the rough equivalent of wiping the data from RAM.
Anyone who is truly security minded should be using whole disk encryption anyway, but even then you have the data accessible from the running OS. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
