lkml.org 
[lkml]   [2015]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/5] RFC: Offer a way for userspace to request real deletion of files
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


\
 
 \ /
  Last update: 2015-03-02 11:41    [W:1.019 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site