Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751638AbcCRW4R (ORCPT ); Fri, 18 Mar 2016 18:56:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:59210 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751397AbcCRW4O (ORCPT ); Fri, 18 Mar 2016 18:56:14 -0400 From: NeilBrown To: "Theodore Ts'o" , Dave Chinner Date: Sat, 19 Mar 2016 09:55:57 +1100 Cc: Linus Torvalds , 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 In-Reply-To: <20160315225224.GD23848@thunk.org> References: <20160311223047.GZ30721@dastard> <20160312003556.GF32214@thunk.org> <20160313233049.GA30721@dastard> <56E69398.7030508@redhat.com> <20160314144603.GO29218@thunk.org> <20160315201431.GG30721@dastard> <20160315223313.GH30721@dastard> <20160315225224.GD23848@thunk.org> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-suse-linux-gnu) Message-ID: <87d1qre6pu.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2866 Lines: 67 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, Mar 16 2016, Theodore Ts'o wrote: > On Wed, Mar 16, 2016 at 09:33:13AM +1100, Dave Chinner wrote: >>=20 >> Stale data escaping containment is a security issue. Enabling >> generic kernel mechanisms to *enable containment escape* is >> fundamentally wrong, and relying on userspace to Do The Right Thing >> is even more of a gamble, IMO. > > We already have generic kernel mechanisms such as "the block device". P This is a bit of an 'off-the-wall' suggestion, but I agree that these things that might be of value to user-space file servers do seem a lot like block devices. So why not make them look exactly like block devices? i.e. a new open flag O_BLOCKDEV which, when combined with O_CREAT creates a thing that is managed in the filesystem much like a file, but that appears to user-space like a block device. The major/minor numbers would be essentially meaningless - the filesystem wouldn't call init_special_inode() like it does on normal block devices, it would retain control itself. That would make the content invisible to backups and rsync and all the things that Dave has raised as potential concerns. And it would be no surprise if the contents included stale data because that is exactly what you get when you create a new logical volume with LVM2. The block device would initially be of size zero, but could be resized using fallocate (which soon will work on block devices), which can request zeros, leave holes, or with Teds new FALLOC flag (that would only be permitted on block devices) could allocate uninitialized space. Rules for using O_BLOCKDEV would still need to be clarified - mount option, access to underlying block device, CAP_MKNOD .. whatever. I think that being able to use a filesystem as a logical volume manager is an extremely interesting idea.... we might even end up with a filesystem interface on device-mapper :-) NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW7Id9AAoJEDnsnt1WYoG5bGQQAJO6XM3jDsxlg/s5y6CmLfnU yEsFGFdD+7Y9SgCRBrCNKtEXuz44B0SGR6aroJRe3lzqM8JRMJZHVjPGc2o1krw3 qP9RlCNuL2AWTY/G13VFAByqDYGOh7WwQdFakeXM3yLVxMpmscr2bXKoEoexy8mN 6Iv9/TQ6Jow1yW3dAVNTotaeLBrltQ2JUVsgheKEBg88E7c36UY2y9cWLAuqWRws Nfbn6rJm7qsrXpCHc313f73lVruX1xFSI5GZGdt8lnaTV2upXVWU8UqJSyymODc3 YljZFMOvN2O4peKOjHDsRTcc+JAM/3qqMeIrQrwfCgqEvMl4cN5xQ016MDA6R49g go0thJ/jTwawCuCg+5zwqMV3tLqtZEggNq30c9XmyQXx+I0jHYJMYGkF9Nf9NfwN 6ujSaLpSj29nABS14AjtXdmAagYosu/fuEP2tb3ghmDjSkoRICPrlnDmPCVYV5eG x63AINNK5u7h8/MnmHio1ZHu+Z2nxTFDEH1nPusEsXC0K4VXyM7lbxmV8rn4gWbB bAHxOXehLXpUGVCEZqRV5mWTBaZlvH7F6TeCauZNtNQj9ZCjCOYf1o8LSvtZFPjz QiqN3SSYNWVBdRr7LGOuIBLxAMsNLpaD5Mm7p8F75k6fzfQV7RI1sQDBGp46VPWq VkFv2yTMnFuHOuVvqgw/ =EPYc -----END PGP SIGNATURE----- --=-=-=--