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

[Alexander Holler <holler@ahsoftware.de>]

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