From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f199.google.com (mail-wr0-f199.google.com [209.85.128.199]) by kanga.kvack.org (Postfix) with ESMTP id C2C0B6B025F for ; Wed, 16 Aug 2017 06:35:26 -0400 (EDT) Received: by mail-wr0-f199.google.com with SMTP id 49so4607564wrw.12 for ; Wed, 16 Aug 2017 03:35:26 -0700 (PDT) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com. [2a00:1450:400c:c0c::244]) by mx.google.com with ESMTPS id u11si937347edj.508.2017.08.16.03.35.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 03:35:25 -0700 (PDT) Received: by mail-wr0-x244.google.com with SMTP id y67so2281542wrb.3 for ; Wed, 16 Aug 2017 03:35:25 -0700 (PDT) Date: Wed, 16 Aug 2017 13:25:26 +0300 From: "Kirill A. Shutemov" Subject: Re: [PATCH v4 3/3] fs, xfs: introduce MAP_DIRECT for creating block-map-sealed file ranges Message-ID: <20170816102526.kksbsvcr5cqcf35k@node.shutemov.name> References: <150277752553.23945.13932394738552748440.stgit@dwillia2-desk3.amr.corp.intel.com> <150277754211.23945.458876600578531019.stgit@dwillia2-desk3.amr.corp.intel.com> <20170815091836.c3xpsfgfwz7w35od@node.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Dan Williams Cc: "Darrick J. Wong" , Jan Kara , "linux-nvdimm@lists.01.org" , Linux API , Dave Chinner , "linux-kernel@vger.kernel.org" , linux-xfs@vger.kernel.org, Linux MM , Jeff Moyer , Alexander Viro , Andy Lutomirski , linux-fsdevel , Ross Zwisler , Christoph Hellwig On Tue, Aug 15, 2017 at 10:11:27AM -0700, Dan Williams wrote: > > We had issues before with user-imposed ETXTBSY. See MAP_DENYWRITE. > > > > Are we sure it won't a source of denial-of-service attacks? > > I believe MAP_DENYWRITE allowed any application with read access to be > able to deny writes which is obviously problematic. MAP_DIRECT is > different. You need write access to the file so you can already > destroy data that another application might depend on, and this only > blocks allocation and reflink. > > However, I'm not opposed to adding more safety around this. I think we > can address this concern with an fcntl seal as Dave suggests, but the > seal only applies to the 'struct file' instance and only gates whether > MAP_DIRECT is allowed on that file. The act of setting > F_MAY_SEAL_IOMAP requires CAP_IMMUTABLE, but MAP_DIRECT does not. This > allows the 'permission to mmap(MAP_DIRECT)' to be passed around with > an open file descriptor. Sounds like a good approach to me. -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org