From patchwork Fri Sep 8 00:12:01 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Halcrow X-Patchwork-Id: 811266 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-ext4-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.b="mrG8Ph7D"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3xpHng6Th8z9s81 for ; Fri, 8 Sep 2017 10:12:23 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752653AbdIHAMW (ORCPT ); Thu, 7 Sep 2017 20:12:22 -0400 Received: from mail-pg0-f52.google.com ([74.125.83.52]:37468 "EHLO mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752495AbdIHAMV (ORCPT ); Thu, 7 Sep 2017 20:12:21 -0400 Received: by mail-pg0-f52.google.com with SMTP id d8so2100441pgt.4 for ; Thu, 07 Sep 2017 17:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=jTHbND+USUoffSm9/ZTc++ND3F8AJEV9q9r/Bg1vV7s=; b=mrG8Ph7D3TOr+pCssmw8w2I6Iribi0ukcRYLp8Z5UqdjAkMNV5wtaeBEmjSKPXkBa8 kcYqtgFeqSpE/991JkLDk05ambc7D+cfPsQ7kvIH+WnhBD2iUBiKNximnfX04SITceK0 Fsiz0P64GvNh9w5EL9zf6GSdKozfYvUe4nmrM/EMc1BvxX+Sx4NzlXC47tzqG79jOMYv +uJr3qkSDLnJu7lnc85F9oyB/a/vvV4YY3iUpe8LxABX5+vDemuxwtpaEH3NLhXGSsz4 rn17DwqwAiqyqQ1q6kyXNb6NU/WspmVscRmJOjuiRg05wXuOD9q8TRGtkPzF04dWXm46 3plg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=jTHbND+USUoffSm9/ZTc++ND3F8AJEV9q9r/Bg1vV7s=; b=ZUD+0HPEeWYgk6BkAM0bokRWssCJnbLlj2Q0J5NqmgaJdXewETexGqlUCLTHwJrpBL hfMVx7fIIrLPmtVpwxzcvQ0x+2lWvxbbQACtioI0i94p2+o6d9s0z2qBKOgLumvZfpS+ 8r4wLGN29ilrhoGF6hdwynduqMq34sHXyPsgkx0FRzeKOc51Qes/iselL0J/5depC+lv JHe0TxxG3YYa6FQDzDoq8WccAckdSf8LMRC6sJXoZkOmVsaMwwEv3pmBVd0doJ7A7di8 NFUT0gBiA8Q/EGtynrG54TPUfZsKR8FF8viv77rvOd7uergdehTJgWEdXG1fxWZMUxOE lskQ== X-Gm-Message-State: AHPjjUjDgFs15Ctl+d3fX+fVIMXENASw/3SCttjoZ5fGMrmHgedQZOxM OxhAxZvzSYyeeAet X-Google-Smtp-Source: ADKCNb5ltTxAE4sTif4Bz3PB5C6oFRbcpdfQQeOs9AoJyvFwsO7mMF57PwhA233mrYIZYbzroPnQvQ== X-Received: by 10.98.11.11 with SMTP id t11mr1240190pfi.16.1504829540444; Thu, 07 Sep 2017 17:12:20 -0700 (PDT) Received: from mhalcrow-linux.kir.corp.google.com ([100.66.175.61]) by smtp.gmail.com with ESMTPSA id d25sm1007805pfb.1.2017.09.07.17.12.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Sep 2017 17:12:19 -0700 (PDT) From: Michael Halcrow To: linux-fscrypt@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, tytso@mit.edu, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org Subject: [PATCH 0/3] fscrypto: Return -EXDEV for link, rename, and cross-rename between incompat contexts Date: Thu, 7 Sep 2017 17:12:01 -0700 Message-Id: <20170908001204.18174-1-mhalcrow@google.com> X-Mailer: git-send-email 2.14.1.581.gf28d330327-goog Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Currently file systems support fscrypto will return -EPERM when the user attempts to link, rename, or cross-rename between two directories that have incompatible encryption policy contexts. User space tools will fail the operation when receiving this errno. With -EXDEV, user space tools will typically fall back to copy-and-delete instead. Our original motivation for returning -EPERM was to force users to try harder when doing these operations, hopefully making them think more carefully about whether what they're doing is secure. One security concern is that when moving files between unencrypted locations into encrypted locations, the data in the unencrypted location will remain in the clear on the storage device until the freed blocks are overwritten at some arbitrary point in the future (if ever). Moving files from encrypted locations into unencrypted locations is also (perhaps more obviously) problematic. Whether making things fail will have the intended effect on users is up for debate. Meanwhile I've had at least one person tell me their userspace tools are failing and that they would prefer seeing the same sort of behavior that they see when (for example) moving files from one project quota hierarchy to another (ext4 returns -EXDEV). Note that xfstests generic/398 will require an update with this change. Michael Halcrow (3): ext4 crypto: Return -EXDEV for link, rename, and cross-rename between incompat contexts F2FS crypto: Return -EXDEV for link, rename, and cross-rename between incompat contexts UBIFS crypto: Return -EXDEV for link, rename, and cross-rename between incompat contexts fs/ext4/namei.c | 6 +++--- fs/f2fs/namei.c | 6 +++--- fs/ubifs/dir.c | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-)