From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751729AbbBGF4x (ORCPT <rfc822;w@1wt.eu>);
	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 <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 7 Feb 2015 00:56:52 -0500
X-Injected-Via-Gmane: http://gmane.org/
To: linux-kernel@vger.kernel.org
From: Russ Dill <Russ.Dill@gmail.com>
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: <loom.20150207T064727-832@post.gmane.org>
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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.