From owner-svn-src-all@FreeBSD.ORG Thu Oct 28 19:27:03 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E50C1065670; Thu, 28 Oct 2010 19:27:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E5E3E8FC08; Thu, 28 Oct 2010 19:27:02 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 6E20946B09; Thu, 28 Oct 2010 15:26:59 -0400 (EDT) Date: Thu, 28 Oct 2010 20:26:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Best In-Reply-To: <20101028182219.GA36559@freebsd.org> Message-ID: References: <201010271848.o9RImNSR019344@svn.freebsd.org> <20101027212601.GA78062@freebsd.org> <4CC899C3.7040107@FreeBSD.org> <20101027214822.GA82697@freebsd.org> <4CC8A89D.5070909@delphij.net> <20101028152418.A916@besplex.bde.org> <20101028095538.24147119@ernst.jennejohn.org> <20101028182219.GA36559@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Doug Barton , d@delphij.net, svn-src-all@FreeBSD.org, Gary Jennejohn , src-committers@FreeBSD.org, Bruce Evans , svn-src-head@FreeBSD.org, Dag-Erling Smorgrav Subject: Re: svn commit: r214431 - head/bin/rm X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 19:27:03 -0000 On Thu, 28 Oct 2010, Alexander Best wrote: >> For example, you could imagine a pathconf() call that asks the file system >> if overwriting a file is likely to result in the data going away -- UFS >> could answer "yes" unless it's snapshotting the file system, and ZFS could >> simply answer "no". >> >> In FreeBSD 9, we're going to have two common file system configurations: >> ZFS and UFS+SUJ; the latter will do overwriting of files just fine on most >> current media. > > i agree. however from this discussion it's become quite obvious that > securely deleting any data on a certain media is a very complex topic. when > the -P option got implemented into rm, securely deleting files was quite an > easy and intuitive task. this has clearly changed. so the question arises, > if securely removing data (maybe also directory entries) shouldn't be > handled by a specially designed utility? > > the pathconf() idea looks very primising. should the return values ("yes" or > "no") simply be hardcoded for every fs? or should they be returned by a > routine which actually veryfies on the fly if overwriting files is possible? Deleting data wasn't simple when rm -P was implemented -- in fact, if I recall, there was significant information available even then that overwrite patterns didn't fully remove file system data from magnetic media in such a way that a qualified attacker couldn't recover it. Bad block relocation in software and hardware is also relevant, and wear-levelling has been used in certain storage devices for quite a while now as well. Today the story has gotten even more complicated: file system snapshot features, copy-on-write file systems, block device-level snapshot features, widespread use of wear-levelling, full data journalling, etc. But that doesn't mean that rm -P still isn't useful :-). I see the point of the new pathconf() being to indicate whether trying to overwrite file data is fundamentally useless. That information could be used in one of two ways: (1) to warn the user that the requested overwrite is unlikely to have helped and (2) to cause the removal to fail if it couldn't possibly have worked. I find (1) more appealing but can see arguments for (2); possibly both should be supported in some or another form. Since there's a whole spectrum of confidence possible in whether an overwrite succeeded, any mechanism like the one I've suggested is necessarily going to involve fairly arbitrary heuristics. In a first generation implementation, I suggest that rm -P should generate a warning only in the following case: - An attempt to overwrite a file on a file system actively performing copy-on-write that would affect the file, such as ZFS, or UFS when there's an active snapshot. After some further cogitation, and if people remain interested, the following further case seems reasonable as well: - An attempt to overwrite a file on a file system is mounted from a geom stack in which at least one component in the stack is performing copy-on-write that would affect the file. The warning should read something along the lines of: rm: /foo/bar: file system may not support data overwrite (-P Or similar. However, rm should still perform the overwrite. To be honest, I'm also fine with there just being a nice caveat in the rm(1) man page. :-) Robert