Re: stacked NFS mounts

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

A day and a half or so ago I wrote

> I'm going to look at 5.2 to see how hard it looks to have
> unmount(,MNT_FORCE) do string comparisons in the mount table instead
> of a namei walk.  There is the case of having two things mounted on
> the same path, but that shouldn't be unsolvable.

I have a proof-of-concept implementation written in 5.2.  I actually
made it a separate flag, MNT_STRING, orthogonal to MNT_FORCE, with a
flag, -s, to make umount(8) use it.

It seems to work.  If I artificially fake the NFS server going dead (by
adding a host reject route for the client's IP on the server), a normal
unmount wedges, but with MNT_STRING|MNT_FORCE it unmounts just fine.
There are probably issues with it, since it's a new and relatively
untested facility, but it may be useful as a starting point.

This is now in my mutant 5.2 src tree.  The commit diff is available
from ftp.rodents-montreal.org, in
/pub/mouse/git-unpacked/Mouse/netbsd-fork/5.2/src/diff/89a4f0d-a744955
(also available over HTTP, though when I look at that view it renders
somewhat brokenly - I *think* this is just a rendering issue), in case
anyone is interested.  And, as always, the whole repo is clonable from
git://git.rodents-montreal.org/Mouse/netbsd-fork/5.2/src as well.

Rather than duplicate the hair involved in dealing with chroot views of
mount paths, I just made it work only for non-chrooted processes.  I
consider it an admin tool for unusual situations, for which use case I
think banning it in chroots is reasonable.  (Without this, a
nonprivileged chroot process can use it to probe non-chrooted mount-on
names, by looking at the errno returned from unmount attempts, which is
information leakage, albeit minor information leakage in most cases.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B