fuse2fs -o ro fails on a root-owned but readable image

[DrDaveD]

In e2fsprogs v1.47.3, and in particular starting with this commit, attempting to use fuse2fs to mount a root-owned but other-readable image file (mode 644) as an unprivileged user gets a Permission denied error.

I added a debug statement

diff --git a/misc/fuse2fs.c b/misc/fuse2fs.c
index 28443fcc..5f36d7b6 100644
--- a/misc/fuse2fs.c
+++ b/misc/fuse2fs.c
@@ -3890,6 +3890,7 @@ int main(int argc, char *argv[])
        ret = 2;
        char options[50];
        sprintf(options, "offset=%lu", fctx.offset);
+       dbg_printf(&fctx, "%s: options=%s, flags=0x%x, fctx.ro: %d\n", __func__, options, flags, fctx.ro);
        err = ext2fs_open2(fctx.device, options, flags, 0, 0, unix_io_manager,
                           &global_fs);
        if (err) {

and found that fuse2fs -o ro mounts with the flag EXT2_FLAG_RW included. Running fuse2fs with -o ro,fuse2fs_debug shows this line:

FUSE2FS (ext3.img): main: options=offset=0, flags=0x4024001, fctx.ro: 1

and the value of EXT2_FLAG_RW is 1 so it is included in the flags. If I try it on the previous commit that bit is not set.

The title of the commit is fuse2fs: make "ro" behavior consistent with the kernel so was this change in behavior intentional?

[tytso]

It was intentional, in that in the commit that you referenced, it states:

This means that ro mounts can recover the journal.

But what we need to do, in order to be consistent with what the kernel does, is to allow a read-only mount where we don't have access to the block device (or image file) if the file system doesn't need to have the journal replayed. If the file system was uncleanly unmounted/shutdown, then if we don't have read-write access, we can't safely mount the file system until the journal is replayed.

So should happen is if the image file or block device is read-only, either it should print a message ""INFO: recovery required on readonly filesystem; write access unavailable, cannot proceed", or if the journal does not need to be replayed, the read-only mount should be allowed to proceed.

[DrDaveD]

I'm trying to do that but the trouble I'm running into is that the global_fs isn't populated until the file is open, so I can't tell if recovery is needed when the open read-write fails. Would it be OK to open it first read-only, and then if it is discovered that the journal needs to be replayed, close and (attempt to) reopen it read-write?

I'm also confused by two blocks of code back to back where one says "Recovering journal" (for has journal and needs recovery) and the next says "fuse2fs does not support using the journal" (for has journal). Which is it?

[tytso]

Yes, we will need to open the file system read-only if -o ro is enabled, and if journal needs to be replayed, we will need to close it, and reopen it read-write, replay the journal, then close the file system (to flush any cached metadata information), and re-open it read-only.

As far as the confusing messages, what is going on is that e2fsprogs (including fuse2fs) has the capability to replay the journal. However, it does not (today) have the ability to make journalled updates. Hence, as the message continues to state, "There may be file system corruption or data loss if the file system is not gracefully unmounted." This message predates fuse2fs to being taught how to replay the journal (using functionality that was originally implemented for e2fsck). I agree it's potentially confusing, especially if both messages are printed.

We added journal replay to fuse2fs because if someone tries to use fuse2fs to access (for example) a USB thumbdrive containing a ext4 file system, and it had been previously mounted on a laptop or desktop using the kernel implementation of ext4, and then the user yanks the thumbdrive out without unmounting it, and then plugs it into another system and tries to use it using fuse2fs, it is highly desireable to replay the journal in fuse2fs to avoid potential data corruption and data loss.