linux-ext4 - Re: [PATCH 1/2] fuse2fs: mount norecovery if main block device is readonly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251017193841.GH6170@frogsfrogsfrogs>
Date: Fri, 17 Oct 2025 12:38:41 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Dave Dykstra <dwd@...n.ch>
Cc: tytso@....edu, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/2] fuse2fs: mount norecovery if main block device is
 readonly

On Thu, Oct 16, 2025 at 02:34:18PM -0500, Dave Dykstra wrote:
> I have a few problems with this patch, details below.
> 
> I have proposed an alternative at
>     https://github.com/tytso/e2fsprogs/pull/250
> and I'll email that here next.
> 
> On Mon, Sep 15, 2025 at 05:03:14PM -0700, Darrick J. Wong wrote:
> ...
> > diff --git a/misc/fuse2fs.c b/misc/fuse2fs.c
> > index 48473321f469dc..fb44b0a79b53e6 100644
> > --- a/misc/fuse2fs.c
> > +++ b/misc/fuse2fs.c
> > @@ -946,6 +946,15 @@ static errcode_t fuse2fs_open(struct fuse2fs *ff, int libext2_flags)
> >  
> >  	err = ext2fs_open2(ff->device, options, flags, 0, 0, unix_io_manager,
> >  			   &ff->fs);
> > +	if (err == EPERM) {
> 
> In my case the error here is EACCES (Permission denied) rather than EPERM
> so I in my patch I included both.

Ok, I'll go update my own patch.

> > +		err_printf(ff, "%s.\n",
> > +			   _("read-only device, trying to mount norecovery"));
> > +		flags &= ~EXT2_FLAG_RW;
> > +		ff->ro = 1;
> > +		ff->norecovery = 1;
> 
> I don't think it's good to switch to read-only+norecovery even when a
> read-write mode was requested.  That goes too far.

The block device cannot be opened for write, so the mount cannot allow
user programs to write to files, and the fs driver cannot recover the
journal and it cannot write to the disk.  The only other choice would
be to fail the mount.

norecovery is wrong though.  The kernel fails the mount if the journal
needs recovery, the block device is ro, and the user didn't specify
norecovery.

> It also doesn't catch when recovery is needed.

What specifically do you mean "catch when recovery is needed"?  68 lines
down from the ext2fs_open2 call is a check for the needsrecovery state,
followed by recovering the journal.

> My proposed patch only reopens read-only
> when ro was requested and then later checks to see if recovery is needed
> and if so, errors out.

Your patch also didn't re-check the feature support after reopening the
block device, which you dismissed even though that can lead to
catastrophic behavior.

--D

> 
> Dave
>