Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752958AbcCKWbK (ORCPT ); Fri, 11 Mar 2016 17:31:10 -0500 Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:37282 "EHLO ipmail06.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752437AbcCKWbI (ORCPT ); Fri, 11 Mar 2016 17:31:08 -0500 Date: Sat, 12 Mar 2016 09:30:47 +1100 From: Dave Chinner To: Linus Torvalds 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 Subject: Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1832 Lines: 42 On Fri, Mar 11, 2016 at 10:25:30AM -0800, Linus Torvalds wrote: > On Fri, Mar 11, 2016 at 9:30 AM, Andy Lutomirski wrote: > > > > What if we had an ioctl to do these data-leaking operations that took, > > as an extra parameter, an fd to the block device node. They allow > > access if the fd points to the right inode and has FMODE_READ (and LSM > > checks say it's okay). Sure, it's awkward, but it's much safer. > > That sounds absolutely horrible. > > I'd *much* prefer the suggestion from Alan to simply have a mount-time > option to enable it. That way, you will never get any surprises, and > no "subtle new behavior for somebody who set their system up in a way > that doesn't allow for this". > > So you'd have to explicitly say "my setup is ok with hole punching". Except it's not hole punching that is the problem. Hoel punching makes sure that the underlying blocksare removed and so whatever data is in them cannot be accessed any more. The problem here is preallocation of unwritten blocks that expose the stale data if the filesystem skips marking those blocks as unwritten. And, so, what happens when a file that is preallocated with the unwritten bit so it exposes stale data then has it's owner/group changed? Or copied by root/user in privileged group to a different location that other users can access? Or any of the other vectors that can result in the stale data being copied/made available to unprivileged users? 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.... Cheers, Dave. -- Dave Chinner david@fromorbit.com