Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751729AbbBGF4x (ORCPT ); Sat, 7 Feb 2015 00:56:53 -0500 Received: from plane.gmane.org ([80.91.229.3]:55695 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750756AbbBGF4w (ORCPT ); Sat, 7 Feb 2015 00:56:52 -0500 X-Injected-Via-Gmane: http://gmane.org/ To: linux-kernel@vger.kernel.org From: Russ Dill Subject: Re: [PATCH 0/5] RFC: Offer a way for userspace to request real deletion of files Date: Sat, 7 Feb 2015 05:56:45 +0000 (UTC) Message-ID: References: <1422896713-25367-1-git-send-email-holler@ahsoftware.de> <54D4B0E0.6050806@ahsoftware.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 100.9.139.246 (Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/41.0.2272.35 Chrome/41.0.2272.35 Safari/537.36) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2562 Lines: 54 Alexander Holler 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/