From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Holler Subject: Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only) Date: Tue, 03 Feb 2015 09:51:00 +0100 Message-ID: <54D08BF4.3000903@ahsoftware.de> References: <1422896713-25367-1-git-send-email-holler@ahsoftware.de> <1422896713-25367-2-git-send-email-holler@ahsoftware.de> <20150203060542.GZ29656@ZenIV.linux.org.uk> <54D071AA.1030302@ahsoftware.de> <20150203075616.GA29656@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Al Viro Return-path: Received: from h1446028.stratoserver.net ([85.214.92.142]:36428 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751099AbbBCIvG (ORCPT ); Tue, 3 Feb 2015 03:51:06 -0500 In-Reply-To: <20150203075616.GA29656@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Am 03.02.2015 um 08:56 schrieb Al Viro: > On Tue, Feb 03, 2015 at 07:58:50AM +0100, Alexander Holler wrote: > >>> Charming. Now, what exactly happens if two such syscalls overlap in time? >> >> What do you think will happen? I assume you haven't looked at how I've >> implemented set_secure_delete(). CHarming. > > AFAICS, you get random unlink() happening at the same time hit by that > mess, whether they'd asked for it or not. What's more, this counter > of yours is *not* guaranteed to be elevated during the final iput() of the > inode you wanted to get - again, ls -lR racing with that syscall can > elevate the refcount of dentry, making d_delete() in vfs_unlink() just > remove that dentry from hash, while keeping it positive. If dentry > reference grabbed by stat(2) is released after both dput() and iput() in > do_unlinkat(), the final iput() will be done when stat(2) drops its > reference to dentry, triggering immediate dentry_kill() (since dentry > has already been unhashed) and dentry_iput() from it. Thanks for the short explanation. I will see if I can make sense out of it for me to get an idea how to solve that. > > IOW, this counter is both too crude (it's fs-wide, for crying out loud) > *and* not guaranteed to cover enough. _IF_ you want that behaviour at Sure it is crude. But it keeps the patches simple. As I've written, unlinkat_s() isn't meant for everyday usage, just for the rare case when one really wants to get rid of some contents. Therefor execution speed or an i/o slowdown while the "secure deletion" is in work is totally ignored And that "rare case" doesn't include military security levels, it's just meant for ordinary people which want make it much, much harder for other ordinary people (or geeks or kernel maintainers) to read the deleted content ever again. It's far too easy to use grep or something similiar to find seemingly deleted stuff at device level again (after it was deleted by what filesystems are offering nowadays). Especially if one thinks at stuff like certificates and similiar which can be identified by common patterns (bit sequences) they use. Alexander Holler