Message-ID: <54D08BF4.3000903@ahsoftware.de>
Date: Tue, 03 Feb 2015 09:51:00 +0100
From: Alexander Holler <holler@ahsoftware.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Al Viro <viro@ZenIV.linux.org.uk>
CC: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)
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>
In-Reply-To: <20150203075616.GA29656@ZenIV.linux.org.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2396
Lines: 48

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/