Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp997024ybb; Wed, 1 Apr 2020 13:36:48 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtRMejo6cESQlLayFi5uZOuKM0yxaZoxA89andtywVT3azR0ifQ6hOetqEyrof7QEyF+xmD X-Received: by 2002:a9d:1423:: with SMTP id h32mr18067767oth.359.1585773408371; Wed, 01 Apr 2020 13:36:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585773408; cv=none; d=google.com; s=arc-20160816; b=pEWkncpxfGzW0WHEchG68+QsDXZf8XMb81pKKj9XMCwJXZe/UxTlTwTr3rHjkioflC hGuRFXNcP+AXaBdH7jq1bAZ3rIJvYt1feC5drWzLvgT+AtqYHRVhwOHNM2CYyF8H2xPr BqwIXwlNT9LVJAumNHGhXg26ACoQPMgEiCAaS5zzyO+Qn7xVKAODfMsVHLqV6pbF8qcu k76SBrPCkP8V3fdmBo/GLETCjdnF/6+GHW6YG+SExk0E+H8GCyji4ZZnzqNgGbhpr9YN TsPRpRbicqlqBjkewazSjkkstR3zisbNmo4Wyx19bRHsv8c8ceEGWy+lK05uiyofsS7f T+og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=FVGNNyBBr4pjZQncW6fcDDMQg0cdZ9u8nCPJbqsh/d0=; b=PTcTA9ZVtpcyDWPw/bYWyc5sJ68dPyY1WMRbm4RVBCZupxwmSRyWsZAmhnFjjFce66 IdyF5mcz0hXHxHmKpjmzugUrPWPAJR5X3ttu/CpznOePxPoCpsh4E1JLGs3mP5VGJzq6 +pv5Ds8xGKv/JR/5esL5cNviU3fKccTwyEEulXE1M7GKlH//Jqu2hgO7GGRXS5IsupmN HPu5+waNpKdPJhg/vtBJpRN9S0Uwz7U5uJYDvSw2cy0B78OkE/NtG5SnNRqIxLQfFUNz 47P0AMZaiwePw8XmYnZNlE0eK7DiRjpOT3zWS+oM2LhL2dHIwNynRCErd90ufYWDDic6 jB+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=u6ei9k92; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s28si1361982oij.120.2020.04.01.13.36.36; Wed, 01 Apr 2020 13:36:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=u6ei9k92; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732786AbgDAUfA (ORCPT + 99 others); Wed, 1 Apr 2020 16:35:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:54402 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733008AbgDAUe4 (ORCPT ); Wed, 1 Apr 2020 16:34:56 -0400 Received: from ebiggers-linuxstation.mtv.corp.google.com (unknown [104.132.1.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E3BA1208FE; Wed, 1 Apr 2020 20:34:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585773296; bh=5e/Y+DpQuAnaUyh7Fynhd3HWaNOkr6/qj0jz1CifLP4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=u6ei9k92ro9BSBgwA/aBAWTLPBkDZQOrDOUe+O/JUn7Ij35Qx/ZtCaDclMSQ6gwAL hplacUVQW29LYFuXOg4diN2AKRytaD2yf0teOXqEms7RP9U9F3rkV9PMNAjMcfUQH5 /gX+fEaPOHfvueBVws2FLK3Zi2mObxKqCmAwkZEA= From: Eric Biggers To: linux-ext4@vger.kernel.org Cc: linux-fscrypt@vger.kernel.org Subject: [PATCH 1/4] tune2fs: prevent changing UUID of fs with stable_inodes feature Date: Wed, 1 Apr 2020 13:32:36 -0700 Message-Id: <20200401203239.163679-2-ebiggers@kernel.org> X-Mailer: git-send-email 2.26.0.rc2.310.g2932bb562d-goog In-Reply-To: <20200401203239.163679-1-ebiggers@kernel.org> References: <20200401203239.163679-1-ebiggers@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org From: Eric Biggers The stable_inodes feature is intended to indicate that it's safe to use IV_INO_LBLK_64 encryption policies, where the encryption depends on the inode numbers and thus filesystem shrinking is not allowed. However since inode numbers are not unique across filesystems, the encryption also depends on the filesystem UUID, and I missed that there is a supported way to change the filesystem UUID (tune2fs -U). So, make 'tune2fs -U' report an error if stable_inodes is set. We could add a separate stable_uuid feature flag, but it seems unlikely it would be useful enough on its own to warrant another flag. Signed-off-by: Eric Biggers --- misc/tune2fs.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/misc/tune2fs.c b/misc/tune2fs.c index 314cc0d0..ca06c98b 100644 --- a/misc/tune2fs.c +++ b/misc/tune2fs.c @@ -3236,6 +3236,13 @@ _("Warning: The journal is dirty. You may wish to replay the journal like:\n\n" char buf[SUPERBLOCK_SIZE] __attribute__ ((aligned(8))); __u8 old_uuid[UUID_SIZE]; + if (ext2fs_has_feature_stable_inodes(fs->super)) { + fputs(_("Cannot change the UUID of this filesystem " + "because it has the stable_inodes feature " + "flag.\n"), stderr); + exit(1); + } + if (!ext2fs_has_feature_csum_seed(fs->super) && (ext2fs_has_feature_metadata_csum(fs->super) || ext2fs_has_feature_ea_inode(fs->super))) { -- 2.26.0.rc2.310.g2932bb562d-goog