From patchwork Tue Sep 5 00:32:27 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 13374571 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0DB01CA0FE2 for ; Tue, 5 Sep 2023 15:59:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232110AbjIEP7W (ORCPT ); Tue, 5 Sep 2023 11:59:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58352 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242972AbjIEAdr (ORCPT ); Mon, 4 Sep 2023 20:33:47 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8277A197; Mon, 4 Sep 2023 17:33:43 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1BF08612B4; Tue, 5 Sep 2023 00:33:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43F39C433C7; Tue, 5 Sep 2023 00:33:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1693874022; bh=JUO7xE/c+1mjaLvxjmNdDZXOHT1tOz7iofriQG5oJNw=; h=From:To:Cc:Subject:Date:From; b=c/3Fo3AyhEldHIMOuXzoXgBkuXy6FNQV1zWaV1EXbsNHqgJEkqxqhz6A+uwueu6Sg 9nnKKCU864zD1JUxT7xuR+3YVskJVwJx2Jyqe7j6jWMlfWbbIcKkKERT2VL6MUV3Gt 1t0EbW2ta+NI78z/BBN3aKgjmhMjuhGwZpjdU6ALxK7czlyMo/hxN2LoMH7BvcZOmL aUqEO9IpWNhXyr1fmbth13UKikUetvpyg5kMAdevcYtZs3yMOh64mNO6qcgZl+j2WI B3X5mpPmIdb9o+wIh0NP/LjeU8LoWHITSDOSSwWqpyViCMUJWS4K7ea7urzn+NCTuw ji+rFVGK+8kAg== From: Eric Biggers To: Jan Kara , linux-fscrypt@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, stable@vger.kernel.org Subject: [PATCH] quota: explicitly forbid quota files from being encrypted Date: Mon, 4 Sep 2023 17:32:27 -0700 Message-ID: <20230905003227.326998-1-ebiggers@kernel.org> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org From: Eric Biggers Since commit d7e7b9af104c ("fscrypt: stop using keyrings subsystem for fscrypt_master_key"), xfstest generic/270 causes a WARNING when run on f2fs with test_dummy_encryption in the mount options: $ kvm-xfstests -c f2fs/encrypt generic/270 [...] WARNING: CPU: 1 PID: 2453 at fs/crypto/keyring.c:240 fscrypt_destroy_keyring+0x1f5/0x260 The cause of the WARNING is that not all encrypted inodes have been evicted before fscrypt_destroy_keyring() is called, which violates an assumption. This happens because the test uses an external quota file, which gets automatically encrypted due to test_dummy_encryption. Encryption of quota files has never really been supported. On ext4, ext4_quota_read() does not decrypt the data, so encrypted quota files are always considered invalid on ext4. On f2fs, f2fs_quota_read() uses the pagecache, so trying to use an encrypted quota file gets farther, resulting in the issue described above being possible. But this was never intended to be possible, and there is no use case for it. Therefore, make the quota support layer explicitly reject using IS_ENCRYPTED inodes when quotaon is attempted. Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers --- fs/quota/dquot.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) base-commit: 708283abf896dd4853e673cc8cba70acaf9bf4ea diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c index 9e72bfe8bbad9..7e268cd2727cc 100644 --- a/fs/quota/dquot.c +++ b/fs/quota/dquot.c @@ -2339,6 +2339,20 @@ static int vfs_setup_quota_inode(struct inode *inode, int type) if (sb_has_quota_loaded(sb, type)) return -EBUSY; + /* + * Quota files should never be encrypted. They should be thought of as + * filesystem metadata, not user data. New-style internal quota files + * cannot be encrypted by users anyway, but old-style external quota + * files could potentially be incorrectly created in an encrypted + * directory, hence this explicit check. Some reasons why encrypted + * quota files don't work include: (1) some filesystems that support + * encryption don't handle it in their quota_read and quota_write, and + * (2) cleaning up encrypted quota files at unmount would need special + * consideration, as quota files are cleaned up later than user files. + */ + if (IS_ENCRYPTED(inode)) + return -EINVAL; + dqopt->files[type] = igrab(inode); if (!dqopt->files[type]) return -EIO;