Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752748AbcCOV3f (ORCPT ); Tue, 15 Mar 2016 17:29:35 -0400 Received: from imap.thunk.org ([74.207.234.97]:48064 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750701AbcCOV3c (ORCPT ); Tue, 15 Mar 2016 17:29:32 -0400 Date: Tue, 15 Mar 2016 17:29:08 -0400 From: "Theodore Ts'o" To: Linus Torvalds Cc: Dave Chinner , Ric Wheeler , Andy Lutomirski , One Thousand Gnomes , 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: <20160315212908.GB23848@thunk.org> Mail-Followup-To: Theodore Ts'o , Linus Torvalds , Dave Chinner , Ric Wheeler , Andy Lutomirski , One Thousand Gnomes , 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 References:

<20160311223047.GZ30721@dastard> <20160312003556.GF32214@thunk.org> <20160313233049.GA30721@dastard> <56E69398.7030508@redhat.com> <20160314144603.GO29218@thunk.org> <20160315201431.GG30721@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1713 Lines: 37 On Tue, Mar 15, 2016 at 01:43:01PM -0700, Linus Torvalds wrote: > Put another way: this is not about theoretical leaks - because those > are totally irrelevant (in theory, the original discard writer had > access to all that stale data anyway). This is about making it a > practical interface that doesn't have serious hidden gotchas. So there have been two interfaces proposed so far: 1) A mount option which specifies the group id under which a program must be running in order to have the permission to use FALLOC_FL_NO_HIDE_STALE flag in the fallocate system call. 2) The program must have read access to the underlying block device inode under which the file system is mounted in order to have the permission to use the FALLOC_FL_NO_HIDE_STALE flag in the fallocate system call. In both cases, the application has to be make C source code changes to use this feature, and the system administrator has to set up the application so it has the privileges to use it. In the case of #1, the sysadmin has to specify a mount option as well. We're doing #1 in production in a very large number of mounted disks today. Linus has suggested #2, although there was some concern that screw-up in the user namespaces configuration could result in accidentally in a security exposure. (To which my response is, as opposed to the gazillions of other security nightmares which the user namespace makes us vulnerable to?) Still, my preference is for #1, since the mount option acts as an additional control for those really paranoid types that seem convinced that it can't be used safely, and it's what we're doing in production already. I'm open to #2 if other people are OK with it, though. Cheers, - Ted