From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B23BEC4360C for ; Wed, 25 Sep 2019 12:07:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7D81E21655 for ; Wed, 25 Sep 2019 12:07:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="S/A9tkO1" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405385AbfIYMHr (ORCPT ); Wed, 25 Sep 2019 08:07:47 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:45313 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388199AbfIYMHr (ORCPT ); Wed, 25 Sep 2019 08:07:47 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1EAC6224DC; Wed, 25 Sep 2019 08:07:45 -0400 (EDT) Received: from imap37 ([10.202.2.87]) by compute3.internal (MEProxy); Wed, 25 Sep 2019 08:07:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=on/VQ5 eHbmJCO8XUQdTV6gYockvWAtQkQ7buFdi82FM=; b=S/A9tkO1+QkKiB5znDHlq8 H6/wVx6EMzl6lBe7ObWrK6yTjHBb6LN73+6646CZyI4sgnMsH59AWYALMGMYC9ix GVHpqWtsMubRypHQUMCWnWlu3Pdezyd8LQZ9zl33wJF77kFmS6ZJTNRY4RchnHVU OGGX4YCuUcsv/zI5NyqjEL7j9wvikwWh+Jn1CxMquJ3OL8HqgzKatkdrCJTgQ0Eh hA8+Bvj6pZXH6MpQ9Js8Ropbu8z30Qp2VqhfiQWBKA5tglagGiFPd9NXUlMQMcKJ OZ0U2amNLxysIPTXwBLjO3W/CBve7betm5xPWToxzii2H2Y8HBQGa/E/0HkEhdxw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrfedvgdeglecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfveholhhi nhcuhggrlhhtvghrshdfuceofigrlhhtvghrshesvhgvrhgsuhhmrdhorhhgqeenucfrrg hrrghmpehmrghilhhfrhhomhepfigrlhhtvghrshesvhgvrhgsuhhmrdhorhhgnecuvehl uhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 89255684005E; Wed, 25 Sep 2019 08:07:43 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-305-g4111847-fmstable-20190924v1 Mime-Version: 1.0 Message-Id: <60c48ac5-b215-44e1-a628-6145d84a4ce3@www.fastmail.com> In-Reply-To: <20190925071129.GB804@dread.disaster.area> References: <230a76e65372a8fb3ec62ce167d9322e5e342810.1568875700.git.osandov@fb.com> <20190924171513.GA39872@vader> <20190924193513.GA45540@vader> <20190925071129.GB804@dread.disaster.area> Date: Wed, 25 Sep 2019 08:07:12 -0400 From: "Colin Walters" To: "Dave Chinner" , "Jann Horn" Cc: "Omar Sandoval" , "Aleksa Sarai" , "Jens Axboe" , linux-fsdevel , linux-btrfs@vger.kernel.org, "Linux API" , "Kernel Team" , "Andy Lutomirski" Subject: Re: [RFC PATCH 2/3] fs: add RWF_ENCODED for writing compressed data Content-Type: text/plain Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Sep 25, 2019, at 3:11 AM, Dave Chinner wrote: > > We're talking about user data read/write access here, not some > special security capability. Access to the data has already been > permission checked, so why should the format that the data is > supplied to the kernel in suddenly require new privilege checks? What happens with BTRFS today if userspace provides invalid compressed data via this interface? Does that show up as filesystem corruption later? If the data is verified at write time, wouldn't that be losing most of the speed advantages of providing pre-compressed data? Ability for a user to cause fsck errors later would be a new thing that would argue for a privilege check I think.