From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@bugzilla.kernel.org
Subject: [Bug 92271] Provide a way to really delete files, please
Date: Tue, 03 Feb 2015 17:29:29 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
To: linux-ext4@vger.kernel.org
Return-path:
Received: from mail.kernel.org ([198.145.29.136]:38613 "EHLO mail.kernel.org"
rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
id S1751686AbbBCR3c (ORCPT );
Tue, 3 Feb 2015 12:29:32 -0500
Received: from mail.kernel.org (localhost [127.0.0.1])
by mail.kernel.org (Postfix) with ESMTP id 44D6E20272
for ; Tue, 3 Feb 2015 17:29:31 +0000 (UTC)
Received: from bugzilla1.web.kernel.org (bugzilla1.web.kernel.org [172.20.200.51])
by mail.kernel.org (Postfix) with ESMTP id B191120253
for ; Tue, 3 Feb 2015 17:29:29 +0000 (UTC)
In-Reply-To:
Sender: linux-ext4-owner@vger.kernel.org
List-ID:
https://bugzilla.kernel.org/show_bug.cgi?id=92271
--- Comment #22 from Theodore Tso ---
Alexander, merely overwriting the blocks won't necessarily help if you are
using a SSD or something like dm-thin. That's the point; such patches will be
making promises that can't be kept in all circumstances. In the case of an SSD,
it might be require accessing the flash cells directly without the FTL getting
in the way.
So before you advertise such a scheme, you need to be very clear what your
threat model and what capabilities the adversary is supposed to have. And,
also, what responsibility you might bear (or a commercial company like Red Hat
or SuSE might bear --- both in terms of legal liability and reputational
damage) if they advertise such a feature, and then it turns out that the way
the user happened to configure their system, it wasn't secure after all.
-- Ted
--
You are receiving this mail because:
You are watching the assignee of the bug.