kern/120319: fsck on read-only root fs upgrades it to read-write

Yar Tikhiy yar at comp.chem.msu.su
Mon Feb 11 14:10:02 UTC 2008


The following reply was made to PR kern/120319; it has been noted by GNATS.

From: Yar Tikhiy <yar at comp.chem.msu.su>
To: Jaakko Heinonen <jh at saunalahti.fi>
Cc: bug-followup at FreeBSD.org
Subject: Re: kern/120319: fsck on read-only root fs upgrades it to read-write
Date: Mon, 11 Feb 2008 17:04:43 +0300

 On Thu, Feb 07, 2008 at 11:53:23PM +0200, Jaakko Heinonen wrote:
 > On 2008-02-07, Yar Tikhiy wrote:
 > > > This happens because the kernel doesn't set the "ro" mount option
 > > > initially for mounts in vfs_mountroot_try() (vfs_mount.c). ffs_mount()
 > > > remounts a file system as read-write if the "ro" option is missing.
 > > 
 > > You've hit the nail on the head!  Now the question is: Which of the
 > > two functions should be fixed after all?  Some parts of the system
 > > seem to rely solely on MNT_RDONLY to get a read-only mount, so it
 > > might be wrong for ffs_mount() to look for the "ro" option even if
 > > MNT_RDONLY is set in the mount flags.  Any ideas?
 > 
 > Seems that msdosfs, ext2fs, nfs and zfs also rely on "ro" on remount. So
 
 I bet they just had the code copied from the FFS driver.
 
 > changing ffs_mount() means changes for other file systems too to keep
 > their behavior identical. For me the vfs_mountroot_try() approach seems
 > logical because that unifies behavior of mount(8) and
 > vfs_mountroot_try().
 
 I'm afraid that handling MNT_RDONLY versus the "ro" option in the kernel
 hasn't been really consistent since the introduction of nmount(2).  Why
 should a caller of nmount() or vfs_donmount() have to specify both MNT_RDONLY
 and the "ro" option?  And, according to the nmount(2) manpage:
 
      MNT_RDONLY       The file system should be treated as read-only; even the
                       super-user may not write on it.  Specifying MNT_UPDATE
                       without this option will upgrade a read-only file system
                       to read/write.
 
 In fact, it isn't 100% true as the "ro" option is dup'ed to the
 MNT_RDONLY flag in vfs_donmount(); i.e., it's OK to specify "ro"
 only.  Then why is it wrong to specify MNT_RDONLY only?  Now I think
 I'd rather fix vfs_donmount() so that it adds the "ro" option if
 it isn't there but MNT_RDONLY is set.  The function already does
 so if the "rw" option is specified.  But IMHO all this is dirty
 hackery, whose need results from non-conformity in nmount(2) framework
 semantics.
 
 -- 
 Yar


More information about the freebsd-bugs mailing list