Re: stacked NFS mounts

Mouse <[email protected]>
Newsgroups gmane.os.netbsd.devel.kernel
Message-ID <[email protected]>
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		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.