On 2014-08-12 11:52, David Pottage wrote: > > On 11/08/14 03:53, Austin S Hemmelgarn 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. > How would secure deletion interact with file de-duplication? > > For example suppose you and I are both users on a multi user system. We > both obtain copies of the same file independently, and save that file to > our home directories. > > A background process notices that both files are the same and > de-duplicates them. This means that both your file and mine point to the > same blocks on disc. This is exactly the same as would happen if you > made a COW copy of your file, transferred ownership to me, and I moved > it into my home dir. > > You then decide to secure delete your copy of the file. What happens to > mine? If it gets removed, then you have just deleted a file you don't > own, if it does not then the file-system has broken the contract to > secure delete a file when you asked it to. > > Also, what happens if the two files have similar portions, but they are > not identical. For example, if you download and ISO image for ubuntu, > and I download the ISO for kubuntu (at the same version). There will be > a lot of sections that are the same, because they will contain a lot of > packages in common, so there will be large gains in de-duplicating the > similar parts, but most people would consider the files to be different. > > Could this mean that if you secure delete your ubuntu iso, then portions > of my kubuntu iso might become corrupt? > You could work around this by marking the extent, instead of the file (marking a file would mark all of it's extents), and then checking for that marking when the extent is freed (ie, nobody refers to it anymore). While this approach might not seem useful to most people, there are practical use cases for it (even without whole disk encryption). It would be pretty easy actually to integrate this globally for a file-system as a mount option. > Even if we limit secure delete to root, then we still leave the risk of > unintentonaly breaking user files, because non-one realised that all or > part of the file appears in other files via de-duplication. In any case > if secure delete is limited to root, then most people would not find it > useful. (or they would use sudo to do it, which brings us back to the > same problems). > > Basically, I think that file secure deletion as a concept is not > compatible with a 5th generation file system. If you relay want to > securely remove a file, then copy the stuff you need elsewhere, and put > the disc in the crusher. Alternatively put the filesystem in an encypted > container, and then reformat the disc with a different encryption key. > While I agree that the traditional notion of secure deletion doesn't fit in the current generation of file systems, there is still a need for COW filesystems to be able to prevent sensitive data from being exposed during run-time. On any current BTRFS filesystem, it is still possible to find blocks that have been COW'ed (assuming discard is turned off) and have no referents, possibly long after the block itself is freed, and especially if the volume is much larger than the stored data set (like a large majority of desktop users these days) or the workload is not write intensive.
smime.p7s
Description: S/MIME Cryptographic Signature
