e2fsck: don't allow journal inode to have encrypt flag

From: Eric Biggers <[email protected]>

Since the kernel is being fixed to consider journal inodes with the 'encrypt' flag set to be invalid, also update e2fsck accordingly.

---
 e2fsck/journal.c                   |   3 ++-
 tests/f_badjour_encrypted/expect.1 |  30 +++++++++++++++++++++++++++++
 tests/f_badjour_encrypted/expect.2 |   7 +++++++
 tests/f_badjour_encrypted/image.gz | Bin 0 -> 2637 bytes
 tests/f_badjour_encrypted/name     |   1 +
 5 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 tests/f_badjour_encrypted/expect.1
 create mode 100644 tests/f_badjour_encrypted/expect.2
 create mode 100644 tests/f_badjour_encrypted/image.gz
 create mode 100644 tests/f_badjour_encrypted/name

index d802c5e9..343e48ba 100644
@@ -1039,7 +1039,8 @@ static errcode_t e2fsck_get_journal(e2fsck_t ctx, journal_t **ret_journal)
 			tried_backup_jnl++;
 		}
 		if (!j_inode->i_ext2.i_links_count ||
-		    !LINUX_S_ISREG(j_inode->i_ext2.i_mode)) {
+		    !LINUX_S_ISREG(j_inode->i_ext2.i_mode) ||
+		    (j_inode->i_ext2.i_flags & EXT4_ENCRYPT_FL)) {
 			retval = EXT2_ET_NO_JOURNAL;
 			goto try_backup_journal;
 		}

new file mode 100644
index 00000000..e88e3770
@@ -0,0 +1,30 @@
+Superblock has an invalid journal (inode 8).
+Clear? yes
+
+*** journal has been deleted ***
+
+Pass 1: Checking inodes, blocks, and sizes
+Journal inode is not in use, but contains data.  Clear? yes
+
+Pass 2: Checking directory structure
+Pass 3: Checking directory connectivity
+Pass 4: Checking reference counts
+Pass 5: Checking group summary information
+Block bitmap differences:  -(32--33) -(35--49) -(115--1121)
+Fix? yes
+
+Free blocks count wrong for group #0 (926, counted=1950).
+Fix? yes
+
+Free blocks count wrong (926, counted=1950).
+Fix? yes
+
+Recreate journal? yes
+
+Creating journal (1024 blocks):  Done.
+
+*** journal has been regenerated ***
+
+test_filesys: ***** FILE SYSTEM WAS MODIFIED *****
+test_filesys: 11/256 files (0.0% non-contiguous), 1122/2048 blocks
+Exit status is 1

new file mode 100644
index 00000000..a3744874
@@ -0,0 +1,7 @@
+Pass 1: Checking inodes, blocks, and sizes
+Pass 2: Checking directory structure
+Pass 3: Checking directory connectivity
+Pass 4: Checking reference counts
+Pass 5: Checking group summary information
+test_filesys: 11/256 files (9.1% non-contiguous), 1122/2048 blocks
+Exit status is 0

new file mode 100644
index 0000000000000000000000000000000000000000..660496ea5bba9b5589e6ce522feb998a56ab946a
GIT binary patch

new file mode 100644
index 00000000..e8f4c04f
@@ -0,0 +1 @@
+journal inode has encrypt flag

base-commit: aad34909b6648579f42dade5af5b46821aa4d845

2.38.1

Good to have a test case for this.

In the past Ted has asked that new test cases are generated via mke2fs and debugfs in "f_XXX/script" file rather than a binary image, if possible. That avoids saving a binary blob in Git, and also makes it much more clear in the future what is done to the filesystem to corrupt it, rather than having to reverse engineer this from the bits on disk.

Something like tests/f_dup4/script is a good example of this. You may be able to use something as simple as the following:

    touch $TMPFILE
    $MKE2FS -t ext4 -b 1024 -J size=4 ... $TMPFILE 16384
    $DEBUGFS -w -R 'set_inode_field <8> flags 0x800' $TMPFILE
    . $cmd_dir/run_e2fsck

It might be more involved, depending on how the journal was corrupted. For complex debugfs changes, it is better to use a "here" document to perform multiple commands than running debugfs multiple times.

The script is also much more compact than the binary image, and tolerates changes a lot better as well.

Cheers, Andreas

I didn't realize the test suite supported this. Done in v2, thanks!

- Eric