Sometimes, there's the need to delete a file in a filesystem, and make sure that the file is truly gone. A file that contains sensitive passwords, for example, should be throughly wiped from the disk.
Issuing a simple rm on a typical file system deletes the inode ("pointer") to the file, but it doesn't delete the file's content in the physical disk – these are left there until they are overwriten when the filesystem needs the free space.
On many file systems, the shred program enables such secure deletion.
However, on a CoW filesystem such as btrfs, this approach is useless.
The problem is exacerbated by the fact that the file may be present on volume snapshots.
Is there a way to securely delete a file on a btrfs filesystem?
Is it sufficient to delete all pointers (on all volumes) and fill the free space with zeros?
Best Answer
Secure deletion is a tough proposition on any filesystem. Unless the filesystem is very peculiar and guarantees that there aren't other copies of the file lying around, you need to clear all the free space on the device. While you are more likely to find many bits of the file on copy-on-write filesystems, even more “static” filesystems don't have this guarantee in practice, because many files get edited, so there are bit from former versions of the file lying around.
Note that erasing with zeroes is as good as erasing with random bytes, and you don't need multiple passes. Erasing with zeroes left residual data that could be partially recovered in lab conditions with 1980's hard disk technologies; this is no longer applicable today. See Why is writing zeros (or random data) over a hard drive multiple times better than just doing it once?
You can get rid of the cleartext confidential data by encrypting everything on the disk. Set up an ecryptfs volume over that filesystem and move all your (confidential) files to it. Then overwrite all the unused space of the filesystem. You can erase most of it by filling the filesystem with
cat /dev/zero >zero. There may still be some information left in incomplete blocks (blocks that contain the last chunk of a file, followed by some garbage — which could be leftovers from a confidential file). To ensure that there are no incomplete blocks, move everything on the filesystem to ecryptfs (ecryptfs's files use whole blocks, at least on typical setups where blocks are 4kB). Make sure to apply this to all volumes and to erase all snapshots containing plaintext confidential data.There may still be some information left in the journal. I don't know how to scrub that.
On SSD, due to block reallocation, there may be data left that can't be read by normal software means but may be recovered by hacking the firmware or with physical access. There your only recourse is a full wipe of the SSD.