Re: [PATCH 0/5] RFC: Offer a way for userspace to request real deletion of files

From: Alexander Holler
Date: Mon Mar 02 2015 - 05:03:38 EST


Am 07.02.2015 um 06:56 schrieb Russ Dill:
Alexander Holler <holler <at> ahsoftware.de> writes:


Hello.

I've set up a repository at github which contains the 3 pathches to add
limited support to the Linux kernel for wiping files on ext4 and (v)fat
with 3 small patches and a total of "9 files changed, 101 insertions(+),
8 deletions(-)" here:

https://github.com/aholler/wipe_lnx

Feel free to send me any comments, patches or even flames in privat
(off-list)! because I don't want to become involved in annoying
discussions here anymore.

Alexander Holler


This is certainly a case of "The Emperor's New Clothes". Lets say I use vim to
edit my file containing my deep dark secrets. Lets strace it and see what
happens when I edit it and save a new copy:

rename("secure_document.txt", "secure_document.txt~") = 0
open("secure_document.txt", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 3
write(3, "secrete:s\n", 10) = 10
fsync(3) = 0
close(3) = 0
chmod("secure_document.txt", 0100664) = 0
setxattr("secure_document.txt", "system.posix_acl_access",
"\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x06\x00\xff\xff\xff\x
ff \x00\x04\x00\xff\xff\xff\xff", 28, 0) = 0
unlink("secure_document.txt~") = 0

You'll find that just about every program that deals with files properly does
something like this. If it didn't, there'd be a good chance of losing all your
work if the computer or program crashed while saving your file. This is layer
one of the problem.

Layer 2 is filesystems, as others have noted, filesystems have all sorts of
paths for blocks no longer being associated with inodes. Log structured file
systems doubly so.

And layer 3, media, which we have no control over and may be storing duplicate
copies of the data for any number of reasons. But as you've pointed out, is
likely to require significant funds to get at.

As pointed out, the best you could do is some sort of flag on the inode that
instructed the filesystem to wipe blocks before separating them from the inode.
Programs would need to be modified though as you can see in the vim case, any
copying of file mode bits are only done after data has been written to disk.

Luckily there is an easy solution out there that solves all these problems.

Sorry for the late answer, haven't seen that comment as I wasn't in cc.

To conclude, thanks for describing the obvious. ;)

But whatever you think, my simple solution is still better than anything the kernel offers. It makes it possible to get rid of the current contents of any file on extN and vfat. And that is much more than the kernel offers now (which is zero or nothing) and is much easier to use than all those other solutions. And the ease of use is important (just rm -w file). So even if that doesn't delete any leftovers from changing a file before, it's still much, much better than nothing.

And if you need more, e.g. a working 's' flag, I assume using my simple approach of temporarily enabling the "discard" mount option (with an overwrite in case discard (trim) isn't available) while something changes a file with the 's' flag could be done with relatively small changes too.

For details of the discard-algorithm I had in mind, please look at

https://github.com/aholler/wipe_lnx/blob/master/patches_kernel/3.19/0002-WIP-fs-implement-blkdev_issue_wipe-and-sb_issue_wipe.patch

which implements it.

I will remove the WIP (Work In Progress) for that patch the next time I change the patches as I think that single patch is already in it's final state.

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/