Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753075AbcCLAeE (ORCPT ); Fri, 11 Mar 2016 19:34:04 -0500 Received: from mail-io0-f195.google.com ([209.85.223.195]:33543 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750787AbcCLAd7 (ORCPT ); Fri, 11 Mar 2016 19:33:59 -0500 MIME-Version: 1.0 In-Reply-To: <20160311223047.GZ30721@dastard> References: <20160303231050.GU29057@dastard> <20160309230819.GB3949@thunk.org> <56E18B9B.5070503@gmail.com> <56E24CA5.3030702@redhat.com> <20160311135952.57a44931@lxorguk.ukuu.org.uk> <20160311223047.GZ30721@dastard> Date: Fri, 11 Mar 2016 16:33:58 -0800 X-Google-Sender-Auth: I6AF1ASSTirlIAeGqu3NRXMqCFQ Message-ID: Subject: Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks From: Linus Torvalds To: Dave Chinner Cc: Andy Lutomirski , One Thousand Gnomes , Ric Wheeler , "Theodore Ts'o" , Gregory Farnum , "Martin K. Petersen" , Christoph Hellwig , "Darrick J. Wong" , Jens Axboe , Andrew Morton , Linux API , Linux Kernel Mailing List , shane.seymour@hpe.com, Bruce Fields , linux-fsdevel , Jeff Layton , Eric Sandeen Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2011 Lines: 46 On Fri, Mar 11, 2016 at 2:30 PM, Dave Chinner wrote: > On Fri, Mar 11, 2016 at 10:25:30AM -0800, Linus Torvalds wrote: >> >> So you'd have to explicitly say "my setup is ok with hole punching". > > Except it's not hole punching that is the problem. [..] > The problem here is > preallocation of unwritten blocks that expose the stale data if the > filesystem skips marking those blocks as unwritten. Right you are. > It's all well and good to restrict access to the fallocate() call to > limit who can expose stale data, but it doesn't remove the fact it > is easy for stale data to unintentionally escape the privileged > group once it has been exposed because there is no record of the > fact the file contains uninitialised blocks.... Good point. It's not just that the user in question *couldn't* have exposed it other ways by reading the raw device and then writing that info into a file. You're right that the "don't initialize unwritten blocks" thing has a more insidious problem of making it easy to unintentionally expose such data just because you missed an error path (or the process died without ever doing the proper over-write).. It would be much better if we could somehow mitigate just _how_ easy it is to screw up. One way to do that would be to not just require that the user that discards the initializing writes have read access to the underlying device, but perhaps also have some strict requirement that you can discard only if the file you are working with is legible only to you? That would limit the damage, and keep the stale data "private" to the user who is already able to read the raw data off the device. Sure, you can then mark the file read-by-world by others later, but at that point you're kind of *consciously* exposing that stale data (and at that point, you have hopefully cleaned it all up and replaced the stale data with real data). But would that perhaps not be reasonable for the kind of use cases that google has now? Linus