Re: [PATCH] private mounts

From: Ram
Date: Wed Apr 27 2005 - 16:41:57 EST


On Wed, 2005-04-27 at 13:03, Miklos Szeredi wrote:
> > sorry, I think I have not raised by concern clearly.
> >
> > I am mostly talking about the semantics of 'invisible/private mount' not
> > FUSE in particular, since the kernel patch brings in new feature
> > to VFS.
> >
> > My understanding of private mount is:
> > 1. The contents of the private mount is visible only to the
> > mount owner.
> > 2. The vfsmount of the private mount is only accessible to
> > the mount owner, and only the mount owner can mount anything
> > on top of it.
> >
> > But I dont see (2) is being checked for.
>
> It's automatically enforced, since the mount syscall itself will use
> the same path lookup mechanism as any other filesystem operation.
>
> > I can overmount something on top of a private mount owned by someother
> > user. I verified that with your patch.
> >
> > 1. do a invisible mount as user 'x' on /mnt
> > 2. do a visible mount as root on /mnt and it *succeeds* and also masks
> > the earlier mount to the user 'x'.
>
> Yes, because a later mount on a _same_ dentry will mask an earlier
> mount. But that does not mean, that the mount happened on the private
> mount's root.
>
> You can check where the mount ended up, by having a shell of 'x' cd to
> the private mount. Then do the overmount. If the shell can still see
> the private mount, then the overmount did not in fact mount over the
> private root.

ok. Generally overmounts are done on the root dentry of the topmost
vfsmount. But in this case, your patch mounts it on the same dentry
as that of the private mount.

Essentially I was always under the assertion that 'a dentry can hold
only one vfsmount'. But invisible mount seem to invalidate that
assertion. Don't see any bad effects of that. Probably some VFS
experts may. (or probably my assertion is wrong to begin with)

RP


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/