From patchwork Fri Jun 16 18:34:11 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 9793171 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B3B5B60231 for ; Fri, 16 Jun 2017 18:34:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A9DB62866B for ; Fri, 16 Jun 2017 18:34:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9BEF32866E; Fri, 16 Jun 2017 18:34:52 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4614A2866B for ; Fri, 16 Jun 2017 18:34:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750844AbdFPSev (ORCPT ); Fri, 16 Jun 2017 14:34:51 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:34572 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750787AbdFPSeu (ORCPT ); Fri, 16 Jun 2017 14:34:50 -0400 Received: by mail-pf0-f195.google.com with SMTP id d5so7708120pfe.1; Fri, 16 Jun 2017 11:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=SodKdxcrzfVsRiltGTGINtbOe6gsdCz0h1ykASw422w=; b=LP3TvxmHVbuDerubmqhMFS6NABle7QuhuYWzOXN4ELjfmGQPMCAXXBpl1Hom+LkohC lTMh3Zk4KNhnJVNQLkd4B8pEVdPeIYelZ2xu4cr0t7os3zvaHGfm8X2XjRmJmFWb+czV y0rZlpDnaPc56ewup1vFvAIra+emDGaml17NdVc5T9A7GMVefW43eEXGXrcGkci0gHKv CwUEiVI6geaDN26yNwd6TDeh7ctzjFG3WXDgFTOC8DtPMhgwXAKDnuoAHQYIfLbgMjh8 Mge7OlY+iJ9SkDUWKqQelosmjxIH0OTqfauzb3YBE6NGuphGqUGRo45X6+gYfY3WkPmR 89jg== 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=SodKdxcrzfVsRiltGTGINtbOe6gsdCz0h1ykASw422w=; b=n4xFlA8A6PUxPhvuNtAL/dLz6UC3tcIxA189Kggk+086cwIuNQkBeEFb323SIJSqtx e/qIOKMST6RBMkEFAy5Y2EY9P9vC/Gc6HjXuBBgaDOjmA5eUPKGyagu/Xn7O0J6FBY1d ANKPi7nRpMRc2oBKGafSa64wadDDxsIdczcNIb4L2CL05n5Mn6HQ08WRpgFs96aH6QbK gD+ZFQ95ZpC/WoZLpRyjhXjo1+7ELhvAbg3Dew7LCujaqH17HRTRB4kMq/Kn53MNuJJS cJFGwqAjcFihSakh6qeWmAjtyvDMUAJDmp5JhL/be3vL23jt2I6fwuYWtujExfNQ99gs j2Ew== X-Gm-Message-State: AKS2vOyUisjKiB7O+ujQ/gLKUF9OXnoDjkw7jzjx6VtqRJ/x3RNtCjY0 Dtm0qkQuL/rFU9y0kg0= X-Received: by 10.99.188.18 with SMTP id q18mr12815647pge.79.1497638089687; Fri, 16 Jun 2017 11:34:49 -0700 (PDT) Received: from ebiggers-linuxstation.kir.corp.google.com ([100.66.174.81]) by smtp.gmail.com with ESMTPSA id y68sm5794131pfy.12.2017.06.16.11.34.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Jun 2017 11:34:48 -0700 (PDT) From: Eric Biggers To: linux-ext4@vger.kernel.org Cc: linux-fscrypt@vger.kernel.org, Theodore Ts'o , Andreas Dilger , Jaegeuk Kim , Eric Biggers Subject: [PATCH v2] ext4: forbid encrypting root directory Date: Fri, 16 Jun 2017 11:34:11 -0700 Message-Id: <20170616183411.31587-1-ebiggers3@gmail.com> X-Mailer: git-send-email 2.13.1.518.g3df882009-goog Sender: linux-fscrypt-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Eric Biggers Currently it's possible to encrypt all files and directories on an ext4 filesystem by deleting everything, including lost+found, then setting an encryption policy on the root directory. However, this is incompatible with e2fsck because e2fsck expects to find, create, and/or write to lost+found and does not have access to any encryption keys. Especially problematic is that if e2fsck can't find lost+found, it will create it without regard for whether the root directory is encrypted. This is wrong for obvious reasons, and it causes a later run of e2fsck to consider the lost+found directory entry to be corrupted. Encrypting the root directory may also be of limited use because it is the "all-or-nothing" use case, for which dm-crypt can be used instead. (By design, encryption policies are inherited and cannot be overridden; so the root directory having an encryption policy implies that all files and directories on the filesystem have that same encryption policy.) In any case, encrypting the root directory is broken currently and must not be allowed; so start returning an error if userspace requests it. For now only do this in ext4, because f2fs and ubifs do not appear to have the lost+found requirement. We could move it into fscrypt_ioctl_set_policy() later if desired, though. Signed-off-by: Eric Biggers Reviewed-by: Andreas Dilger --- v2: use EPERM instead of EBUSY, and tweak commit message fs/ext4/super.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index d37c81f327e7..d5b5c80c23f5 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -1145,6 +1145,15 @@ static int ext4_set_context(struct inode *inode, const void *ctx, size_t len, handle_t *handle = fs_data; int res, res2, retries = 0; + /* + * Encrypting the root directory is not allowed because e2fsck expects + * lost+found to exist and be unencrypted, and encrypting the root + * directory would imply encrypting the lost+found directory as well as + * the filename "lost+found" itself. + */ + if (inode->i_ino == EXT4_ROOT_INO) + return -EPERM; + res = ext4_convert_inline_data(inode); if (res) return res;