Re: [PATCH 1/2 v3] EXT4: Secure Delete: Zero out file data

From: Amir Goldstein <amir73il@gmail.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Allison Henderson <achender@linux.vnet.ibm.com>,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH 1/2 v3] EXT4: Secure Delete: Zero out file data
Date: Fri, 8 Jul 2011 09:11:53 +0300	[thread overview]
Message-ID: <CAOQ4uxgWCn2u5gbkPRAwf1vsJrADLXA8+aj2Yq_CZheDTMu24w@mail.gmail.com> (raw)
In-Reply-To: <7AE9DA58-62BA-4FE9-B4C0-AEB6D46DB096@dilger.ca>

On Fri, Jul 8, 2011 at 5:46 AM, Andreas Dilger <adilger@dilger.ca> wrote:
> On 2011-07-07, at 6:09 PM, Amir Goldstein wrote:
>> On Thu, Jul 7, 2011 at 11:19 PM, Allison Henderson
>> <achender@linux.vnet.ibm.com> wrote:
>>>
>>> Ah, ok then.  Yes, part of the requirements was to make secure delete work
>>> for partial truncates, punch hole, and also indexed files.  So that will
>>> save me some time if I can get the migrate routines work.  Thx for the
>>> pointers all!
>>
>> I realized that there is a basic flaw in the concept of deferred-secure-delete.
>> From a security point of view, after a crash during a secure-delete,
>> if the file is not there, all its data should have been wiped.
>> Orphan cleanup on the next mount may be done on a system that
>> doesn't respect secure delete.
>> So for real security, the unlink/truncate command cannot return before
>> all data is wiped.
>
> I don't necessarily agree.  People who are using secure delete don't
> necessarily want their performance to go into the toilet, which is what
> would happen if each unlink/zero happened sequentially.  It is far more
> efficient to submit a large batch of unlink/zero operations and then do
> an sync() or fsync() at the end.  This allows multiple journal operations
> to be coalesced (e.g. unlinks from directory) and block zero requests to
> be merged.
>
>> The unlink/truncate metadata changes must not even be committed
>> before all data is wiped (or at least part of the data with partial truncate).
>
> That depends on the user, I think.  If someone does "rm -r {dir}" it may
> be better that the files are removed from the namespace more quickly, and
> secure deleted (in a batch) more quickly, than having "rm" wait for each
> file to be unlinked and maybe leave files in the namespace that didn't
> even get a chance to be unlinked.
>

if my system crashes in the middle of "rm -rf my_darkest_secrets/"
I want to be able to see if there are leftovers after reboot, therefore
the directory and files cannot be removed from namespace before
I get the secured delete guaranty.

Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html