[{"id":1765650,"web_url":"http://patchwork.ozlabs.org/comment/1765650/","msgid":"<20170908231223.GA71686@gmail.com>","list_archive_url":null,"date":"2017-09-08T23:12:23","subject":"Re: [PATCH 0/3] fscrypto: Return -EXDEV for link, rename, and\n\tcross-rename between incompat contexts","submitter":{"id":65202,"url":"http://patchwork.ozlabs.org/api/people/65202/","name":"Eric Biggers","email":"ebiggers3@gmail.com"},"content":"Hi Michael,\n\nOn Thu, Sep 07, 2017 at 05:12:01PM -0700, Michael Halcrow wrote:\n> Currently file systems support fscrypto will return -EPERM when the\n> user attempts to link, rename, or cross-rename between two directories\n> that have incompatible encryption policy contexts. User space tools\n> will fail the operation when receiving this errno. With -EXDEV, user\n> space tools will typically fall back to copy-and-delete instead.\n\nMention 'mv' as an example to make it more concrete?\n\n> Our original motivation for returning -EPERM was to force users to try\n> harder when doing these operations, hopefully making them think more\n> carefully about whether what they're doing is secure. One security\n> concern is that when moving files between unencrypted locations into\n> encrypted locations, the data in the unencrypted location will remain\n> in the clear on the storage device until the freed blocks are\n> overwritten at some arbitrary point in the future (if ever). Moving\n> files from encrypted locations into unencrypted locations is also\n> (perhaps more obviously) problematic.\n> \n> Whether making things fail will have the intended effect on users is\n> up for debate. Meanwhile I've had at least one person tell me their\n> userspace tools are failing and that they would prefer seeing the same\n> sort of behavior that they see when (for example) moving files from\n> one project quota hierarchy to another (ext4 returns -EXDEV).\n\nThere are arguments in favor of this, but I'm worried that people will think\nthey can encrypt their files by \"moving\" them into an encrypted directory. In\nfact, the unencrypted data will still be on-disk in the free blocks. When\npeople say they want 'mv' to work, do they actually understand that it usually\ndefeats the purpose of encryption? Or are they naively assuming that deleting a\nfile means its data is gone forever?\n\nIn any case, if we actually do this we'd need to document that mv-ing files into\nan encrypted directory is a bad idea, although it would be of limited use since\nusers rarely read documentation.\n\n> Michael Halcrow (3):\n> ext4 crypto: Return -EXDEV for link, rename, and cross-rename between\n> incompat contexts\n> F2FS crypto: Return -EXDEV for link, rename, and cross-rename between\n> incompat contexts\n> UBIFS crypto: Return -EXDEV for link, rename, and cross-rename between\n> incompat contexts\n\nNits for if we do end up doing this: remove \"cross-rename\" from the subjects to\nshorten them a bit (cross-rename is a type of rename), then add more detail to\nthe patch descriptions, even if that requires duplicating some text. The cover\nletter doesn't get recorded in the commit history, only the actual commits do.\n\nNote: I'm also working on a patchset which adds helper functions\nfscrypt_prepare_link() and fscrypt_prepare_rename(). After that, this error\nwill be chosen by the shared code, rather than individual filesystems.\n\nEric","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org; spf=none (mailfrom)\n\tsmtp.mailfrom=lists.infradead.org (client-ip=65.50.211.133;\n\thelo=bombadil.infradead.org;\n\tenvelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org header.b=\"JIDwkN/I\"; \n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"cPmQ526p\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xptQm0y8yz9sCZ\n\tfor ;\n\tSat, 9 Sep 2017 09:13:04 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dqSSA-0000mq-N7; Fri, 08 Sep 2017 23:12:50 +0000","from mail-pf0-x241.google.com ([2607:f8b0:400e:c00::241])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dqSS7-0000h6-4s\n\tfor linux-mtd@lists.infradead.org; Fri, 08 Sep 2017 23:12:48 +0000","by mail-pf0-x241.google.com with SMTP id f84so2058056pfj.3\n\tfor ;\n\tFri, 08 Sep 2017 16:12:26 -0700 (PDT)","from gmail.com ([2620:15c:17:3:fcba:2a13:d143:a7c0])\n\tby smtp.gmail.com with ESMTPSA id\n\tp71sm5767227pfl.56.2017.09.08.16.12.25\n\t(version=TLS1_2 cipher=AES128-SHA bits=128/128);\n\tFri, 08 Sep 2017 16:12:25 -0700 (PDT)"],"DKIM-Signature":["v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:\n\tMessage-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description:\n\tResent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=kuq8rIPkynPVhfNG1v2HGdxtYXHjn9O7RixwTyaBYnM=;\n\tb=JIDwkN/IWjdas2\n\tXV/4SRLIIAeEN2J0aAltgUuYP4FFlTIA7xHY1+qWG2KU7P/lLqNabxmM6LLqcVSs9BLKdEQrZWPRK\n\tMGysBu2jA9Z4hiyV+Xo5O0SBA7Fv6n3sNSrnY0+JQVWBkVKSQWjgyLq4KhSyyeor75W4KZJWR/fE1\n\tOCx5AQ0zCQyB7Z2DUxwTjkqSPGUxZhQSrKV+77pfVaKPDuwbj6AF4ZXsgNyGSsvTWLmaOg1IJVmCs\n\tKP+PUz+JogZ3PSqZoCIjh4lP9VHiV7OD2n1UMuGwZsmZP2cxSyJPnvad3a3bAJjIfqXmxC7l6apEO\n\tD7Q4FnNpIT/JVxseWehw==;","v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=HaiTiNvn9Q4iKxRiGmyIqHixlHxsmHauDQkqAms1WKM=;\n\tb=cPmQ526pmlN/pvpm5YQr9gZf4T1rMYFnMKvhd76iARxxGbNQ+DW+CtSjnVWdBX1PQj\n\ta70v01+ytExLsKSz//0uGQbCp3Wesyp+NtxG0OWbxQh5Y9QTaFAeH5PVarMHX8zKP4kv\n\t+ierpN/+hqbLD4kJk9KsHFpXRVqS9TELElyhLRb6pm5Xygqb6Hm2bl6PJ7/rwr7lVxIM\n\tSL2xS4hVVMuTcQB6HMBQ+vtA8AcipeaMPPa61Eyckx5hsOUXzPl95xOzyHnzKZswqXLd\n\tI14VhDmwnctwvwEqLod7QfnXYoKdhf5UNeHy2OpE3olO+ovbO6oHwAWEz/bnAV/b+9+l\n\tw1+w=="],"X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:references\n\t:mime-version:content-disposition:in-reply-to:user-agent;\n\tbh=HaiTiNvn9Q4iKxRiGmyIqHixlHxsmHauDQkqAms1WKM=;\n\tb=oBpYItOgubPH+sf+1h/yB+emFlil5CMb6qtnGVqx4XaMlIDU2PluTkdYjVNksCEpiv\n\tqdLHQB9W/a2dEWSrzNy7OmqggTgjL6xOP5zVywx0+PHIAkIfKY2ZHPZ/5JEQ79/D0QnD\n\tjWGZVXCydmfm3+oaIz4zHMC88n48l5RT8mryDA9SAhZdR4aLYMf6t2yM5fhDtmky66PB\n\tT5HFJ/xb4sjNLrPt8+BEwaNvVb3hbn/0hNNtbmIrL7CT+VQC39nf+U7I12in3pPKHnyI\n\tClIukQms0Dke60w9vAgDp3HZAjNKIgPzdxgA6Bir7mLwMVwjlErL3cfeC4UVYQR7ZHNq\n\tXcdA==","X-Gm-Message-State":"AHPjjUia3dxq9yDV/m09Z2AeS9cPTFmvezZbc+H/wvWw9A4wiMn+ZeGQ\n\t+bX1H06hpF7xGQ==","X-Google-Smtp-Source":"ADKCNb4DPDns9GWx40SYr6S6n49igNle/9Vqlt0srXFUhWXD6L2DTIIdEAjE80kUDdnoErMYgJt49Q==","X-Received":"by 10.84.133.67 with SMTP id 61mr5215061plf.385.1504912345857;\n\tFri, 08 Sep 2017 16:12:25 -0700 (PDT)","Date":"Fri, 8 Sep 2017 16:12:23 -0700","From":"Eric Biggers ","To":"Michael Halcrow ","Subject":"Re: [PATCH 0/3] fscrypto: Return -EXDEV for link, rename, and\n\tcross-rename between incompat contexts","Message-ID":"<20170908231223.GA71686@gmail.com>","References":"<20170908001204.18174-1-mhalcrow@google.com>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20170908001204.18174-1-mhalcrow@google.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170908_161247_236381_900CEECE ","X-CRM114-Status":"GOOD ( 17.40 )","X-Spam-Score":"-1.8 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.8 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,\n\tno\n\ttrust [2607:f8b0:400e:c00:0:0:0:241 listed in] [list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends\n\tin digit (ebiggers3[at]gmail.com)\n\t0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\n\tprovider (ebiggers3[at]gmail.com)\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]\n\t-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature\n\t0.1 DKIM_SIGNED Message has a DKIM or DK signature,\n\tnot necessarily valid\n\t-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from\n\tauthor's domain","X-BeenThere":"linux-mtd@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"Linux MTD discussion mailing list ","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"tytso@mit.edu, linux-f2fs-devel@lists.sourceforge.net,\n\tlinux-fscrypt@vger.kernel.org, linux-mtd@lists.infradead.org,\n\tlinux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-mtd\" ","Errors-To":"linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org"}}]