59 lines
3.0 KiB
Diff
59 lines
3.0 KiB
Diff
From 8c7bc71e772899a401b377711b63de32a67c951d Mon Sep 17 00:00:00 2001
|
|
From: Lennart Poettering <lennart@poettering.net>
|
|
Date: Mon, 19 Apr 2021 22:47:33 +0200
|
|
Subject: [PATCH] dissect: ext4 and loopback files are unimpressed by read-only
|
|
access
|
|
|
|
Even if we set up a loopback device read-only and mount it read-only
|
|
this means nothing, ext4 will still write through to the backing storage
|
|
file.
|
|
|
|
Yes, I lost 6h debugging time on this.
|
|
|
|
Apparently, we have to specify "norecovery" when mounting such file
|
|
systems, to force them into truly read-only mode. Let's do so.
|
|
|
|
(cherry picked from commit b620bf332f575ba9b8e4cd60c93446a0c35c23e8)
|
|
|
|
Conflict:different code contexts, manual synchronization path
|
|
Reference:https://github.com/systemd/systemd/commit/8c7bc71e772899a401b377711b63de32a67c951d
|
|
---
|
|
src/shared/dissect-image.c | 21 +++++++++++++++++++++
|
|
1 file changed, 21 insertions(+)
|
|
|
|
diff --git a/src/shared/dissect-image.c b/src/shared/dissect-image.c
|
|
index 210bf31..67cb054 100644
|
|
--- a/src/shared/dissect-image.c
|
|
+++ b/src/shared/dissect-image.c
|
|
@@ -860,6 +860,27 @@ static int mount_partition(
|
|
return -ENOMEM;
|
|
}
|
|
|
|
+ /* So, when you request MS_RDONLY from ext4, then this means nothing. It happily still writes to the
|
|
+ * backing storage. What's worse, the BLKRO[GS]ET flag and (in case of loopback devices)
|
|
+ * LO_FLAGS_READ_ONLY don't mean anything, they affect userspace accesses only, and write accesses
|
|
+ * from the upper file system still get propagated through to the underlying file system,
|
|
+ * unrestricted. To actually get ext4/xfs/btrfs to stop writing to the device we need to specify
|
|
+ * "norecovery" as mount option, in addition to MS_RDONLY. Yes, this sucks, since it means we need to
|
|
+ * carry a per file system table here.
|
|
+ *
|
|
+ * Note that this means that we might not be able to mount corrupted file systems as read-only
|
|
+ * anymore (since in some cases the kernel implementations will refuse mounting when corrupted,
|
|
+ * read-only and "norecovery" is specified). But I think for the case of automatically determined
|
|
+ * mount options for loopback devices this is the right choice, since otherwise using the same
|
|
+ * loopback file twice even in read-only mode, is going to fail badly sooner or later. The usecase of
|
|
+ * making reuse of the immutable images "just work" is more relevant to us than having read-only
|
|
+ * access that actually modifies stuff work on such image files. Or to say this differently: if
|
|
+ * people want their file systems to be fixed up they should just open them in writable mode, where
|
|
+ * all these problems don't exist. */
|
|
+ if (!rw && STRPTR_IN_SET(fstype, "ext3", "ext4", "xfs", "btrfs"))
|
|
+ if (!strextend_with_separator(&options, ",", "norecovery", NULL))
|
|
+ return -ENOMEM;
|
|
+
|
|
r = mount_verbose(LOG_DEBUG, node, p, fstype, MS_NODEV|(rw ? 0 : MS_RDONLY), options);
|
|
if (r < 0)
|
|
return r;
|
|
--
|
|
2.27.0
|
|
|