nmount, mountd drops high order MNT_xx flags during a mount update

Rick Macklem rmacklem at uoguelph.ca
Thu May 7 01:10:06 UTC 2015


David Boyd reported a problem to freebsd-current@ w.r.t. the MNT_AUTOMOUNTED
flag getting cleared by mountd.
  http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel
I just took a look at this and it's kinda ugly...

mountd acquires a list of mounts via getmntinfo() and then does an
nmount() for each of them to get rid of any exports. It uses
f_flags from the statfs returned by getmntinfo() as the 3rd
argument to nmount().
--> Since nmount()s 3rd argument is a "int", it silently drops any
    MNT_xx flag in the high order 32bits of f_flags. At this time,
    it happens that MNT_AUTOMOUNTED is the only one, but...

I can think of a couple of ways to fix this, but I don't like any of
them;-)

1) I suppose mountd could check for each flag set in f_flags and generate
a vfsopts string for it, but that means that every time a new flag that
can be updated is added to MNT_xx, this mountd.c code would have to updated.
--> Ugly!!

2) Require that all flags in MNT_UPDATEMASK be in the low order 32bits.
   I wouldn`t mind this except in means that the MNT_xx flags must be redefined
   and I don`t think that could get MFC`d.

3) Add a new newernmount(2) which has a 64bit flags argument instead of int.

Hopefully someone can think of a nice way to fix this, rick


More information about the freebsd-current mailing list