> On Wed, May 12, 1999 at 11:55:14AM -0400, Alexander Viro wrote:
> >
> >
> > On Wed, 12 May 1999, Matthew Wilcox wrote:
> >
> > >
> > > Hi, Al. You seem to be the most active developer in the VFS, and there
> > > seems to be no official maintainer for it, so I thought I'd try feeding
> > > this patch to you.
> > >
> > > Basically all this patch does is allow you to specify a new directory
> > > when remounting a filesystem. I've had several people using it, and
> > > the one reported bug has been fixed.
> >
> > [snip the patch]
> >
> > It looks sane, but... I don't see where it prevents remounting of /usr to
> > /usr/local/foo. Could you comment on this?
>
> You are correct, it does not prevent that. My reasoning is that root
> has a large number of ways to screw up the system already and detaching
> a filesystem from the namespace by a trick like this is pretty minor
> in comparison. After all, the filesystem may be reattached later.
> A check could be added for the simplest case (preventing mounting a
> filesystem on itself, but consider:
>
> /dev/a /
> /dev/b /b
> /dev/c /b/c
>
> Now remount /b on /b/c/d and it's gone.
>
> Would a check that the current mount point is not a prefix of the new
> mount point be sufficient to catch all possible loops?
Look at it that way: currently filesystems form a tree. Parent can be
found by ->s_root->d_covers->d_inode->i_sb. To prevent loops you need to
preserve tree structure. So yes, checking that we are not moving the fs
under itself is OK here - mounts are serialized wrt each other.
> Another question... is this necessarily a bad thing? Yes, it can get you
> into situations that you can't get into now, but you can always return
> to a sensible state. I'm having trouble thinking of a use for this that
> chroot doesn't give you, to be fair.
suppose /foo is remounted on /foo/bar/baz. And your PWD was /foo/bar.
Bummer. Try to call d_path() after that. Or simply run find.
Another thing to consider: behaviour of NFS-exported filesystems. That has
nothing to loops. Look at the export table handling in knfsd. AFAICS it
may bite you if you are moving the stuff around that way.
And another one: interaction with lookups. I have a nasty gut feeling that
in current form it has really unpleasant races waiting to happen as soon
as we'll allow to move mountpoints *not* dropping the whole tree under
them.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/