On Thu, Nov 20, 2025 at 08:12:19AM +0100, Helg wrote:
> On Wed, Nov 19, 2025 at 05:47:00PM +0000, Crystal Kolipe wrote:
> > Fix a couple of bugs in mount(2):
> > 
> > 
> > 1. The manual page contains the following text:
> > 
> > "For example, most filesystems will not allow a change from read-write to
> >  read-only."
> > 
> > As far as I can tell, this text was added in 4.3BSD-Reno and propogated to
> > OpenBSD via the initial import of the NetBSD tree.
> > 
> > In fact, all of ffs, mfs, tmpfs, ext2fs, and msdosfs allow re-mounting as
> > read-only.
> > 
> > (At least they do via the mount syscall, separately /sbin/mount fails when
> >  given an mfs filesystem as an argument along with -u because it doesn't
> >  understand the 'mfs:*' device string, but that's a separate issue.)
> > 
> > ISO9660, UDF, and ntfs are read-only implementations anyway, so there is no
> > concept of re-mounting from read-write to read-only.
> > 
> > So the idea that _most_ filesystems don't allow a change from read-write to
> > read-only is now clearly outdated.  Let's just remove the example.
> 
> I believe there are some problems with vnode leaking if you remount a
> file system, so there might be some caveates. Others here might know
> more.

I vaguely remember some issues with reading sparse files on volumes mounted
read-only, but I'm pretty sure that was on pre-OpenBSD systems and fixed long
ago.

Apart from that, I've not encountered obvious problems in actual usage.

> I looked at implementing MNT_UPDATE support for fusefs but it turned out
> to be non-trivial and I can't think of a reason why this is needed. If
> you want a read-only FUSE file system, just mount it read-only.

Agreed.

> I want to change the regress/sys/ffs tests to remount the file system
> being tested but due to mfs and fusefs not supporting remounting
> I've put it on hold.

Let's fix that first, at least for mfs, as it would be nice to exercise the
remounting function in regress.

As I mentioned above, the limitation is with /sbin/mount, (and /sbin/mount_mfs
which is of course actually newfs), rather than the mount syscall or the mfs
code.

When called with -u or -oupdate, mount looks at f_mntfromname to find the
device to pass to the filesystem specific mount_* program.  In the case of mfs
we get something like:

mount_mfs -o async -o nodev -o nosuid -o update -o ro mfs:69501 /mfs_volume
                                                      ^^^^^^^^^
                                               not a device special file :-)

... and obviously mount_mfs, (newfs), doesn't implement -o update anyway.

I fixed this locally some time ago (*), by adding code directly to
/sbin/mount that checks for f_fstypename == "mfs" and if so, parsing the
options and doing the mount syscall directly within /sbin/mount.

This avoids adding code to newfs, (which is already a mess because as well as
handling regular filesystem _creation_, it's had mfs mounting shoe-horned in
to it as well), but unfortunately since pledge doesn't have any way to permit
a syscall to mount, I had to modify the pledge promise in such a way that
would likely not be welcome in mainline OpenBSD.

(*) The motivation was that our ports build machines usually run with one or
more mfs filesystems for parts of the ports chroot, and it's useful to be able
to toggle wxallowed, nodev, etc, etc, when you either forget to specify it on
the original mount or are mounting an additional sub-directory that doesn't
need to inherit the flags on the parent filesystem.

So I can see four practical ways to implement updating of mount options for
mfs:

1. Move the call to pledge in /sbin/mount until after a check to see if we
   are updating an mfs filesystem and therefore need to call mount,
   (unlikely to happen).

2. Modify pledge to allow access to mount, (unlikely to happen).

3. Add the code to newfs to parse -u / -o update, (further bloating newfs
   away from it's original well-defined purpose).

4. Write a small helper program, (let's call it update_mfs), that can be
   called from /sbin/mount in the case of updating an mfs filesystem, and
   be free of the pledge restriction against mount.

Locally we've been running with option 2 for quite a while.