From patchwork Wed Jun 14 23:17:53 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 9787619 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 88989602D9 for ; Wed, 14 Jun 2017 23:19:07 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7A1AC28409 for ; Wed, 14 Jun 2017 23:19:07 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6CDB82841E; Wed, 14 Jun 2017 23:19:07 +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 EEE5528409 for ; Wed, 14 Jun 2017 23:19:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752723AbdFNXTG (ORCPT ); Wed, 14 Jun 2017 19:19:06 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:35573 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752671AbdFNXTF (ORCPT ); Wed, 14 Jun 2017 19:19:05 -0400 Received: by mail-pf0-f193.google.com with SMTP id s66so1758472pfs.2; Wed, 14 Jun 2017 16:19:04 -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=gJ14IVM2JJQPHYUu1dYdVx8ePeB+n8XAvtskKlicDYw=; b=s2vnX0BnU5maagU8JS2U7AzemKhYfVbswIyS/NiASbndtwJGISQd5Lgohq1kHO0ulc iG0lrZvquRLlRRYAtDO2cHt4tzY+kq0V/mqrM6aHrETWkYPLfcr4qJwDvP7u069oY/KA BbQmT71KauhwwvufK2Ufuq8UYwQ1jryA+H154qJFhydheRv3ikGvcO/MEo02EaJNRFqY kD6sUoxUk7OgXssEkNeQDCvjAUnPfw/OZCb7Fu8+R5r9+4XXoOwHTeEvasV0jp4OYz6v H6vx2xHL2XxwqPRrlwsPMrRPXaUhO5WQ1EodEs/JsF84MNT71KHJpRjp2UUYEoPslx/V KGZA== 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=gJ14IVM2JJQPHYUu1dYdVx8ePeB+n8XAvtskKlicDYw=; b=ngjntek/1mURCZoZiH6qEAgExUFCAdmn91SC7xWYDWFS7Q0Zgm00kFXqoSLZnq/mft PiO2l/yvEeS4YPu+R3z/qpCtYhte5D/AvzfVeJM6gPHOFa32BGrq4Mbjkrdf+ZH9SBEc Awks2TcVlhpryf2h5g8UaWQ+tyMXoS+z6GGQNC8GzdHy5zOYHoO9yOTM3+GA0BaJHewm cWd7fdY+xrf4gZcEs8qwGB58vCGuhQDFtLqQm8QtZetenTtC1tylM5FFqbP/fVUxEUe/ 3E7W+C8NXhgtaHD2CRCmll4/O9C5SxlFePh54u3vh4hov4NK51lSie9ZnAxcfQ8oXFRi tr2Q== X-Gm-Message-State: AKS2vOxkWnX5IQgsbPAbdbcnI7Lcmi4EDdk8+9zhfCD4OE067Wa/dadv rxgnVIvSOp7Cf6OIiTI= X-Received: by 10.98.105.137 with SMTP id e131mr2285273pfc.56.1497482344197; Wed, 14 Jun 2017 16:19:04 -0700 (PDT) Received: from ebiggers-linuxstation.kir.corp.google.com ([100.66.174.81]) by smtp.gmail.com with ESMTPSA id s4sm1698661pgr.10.2017.06.14.16.19.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 14 Jun 2017 16:19:03 -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] ext4: forbid encrypting root directory Date: Wed, 14 Jun 2017 16:17:53 -0700 Message-Id: <20170614231753.113206-1-ebiggers3@gmail.com> X-Mailer: git-send-email 2.13.1.508.gb3defc5cc-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. It's not clear it would be useful to support encrypting the root directory, because in that scenario dm-crypt might as well be used instead. But in any case, it's broken currently and must not be allowed; so start returning an error if userspace tries to set an encryption policy on the root directory. For now do this in ext4 only, 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 --- fs/ext4/super.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index d37c81f327e7..ed8eacdf61da 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 -EBUSY; + res = ext4_convert_inline_data(inode); if (res) return res;