From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Fri 05 Nov 2004 - 18:58:12 GMT
On Fri, Nov 05, 2004 at 12:03:21PM +0100, Björn Steinbrink wrote:
> On Fri, 5 Nov 2004 03:51:31 +0100
> Björn Steinbrink <bjoern.steinbrink_at_isp4p.net> wrote:
>
> > > why not do it this way:
> > >
> > > 1. get a new namespace
> > > 2. create the vfsmount (for example via --bind)
> > > 3. pivot_root (or similar, maybe new cmd?) to the vfsmount
> > > 4. cleanup the namespace (remove host stuff)
> > > 5. do all required/listed mounts inside that namespace
> > > 6. create the context
> > >
> >
> > I've found an easy way to get a clean namespace using lazy mounts. A
> > short bash script + description can be found at
> > http://doener.homeip.net/doener/vserver/
> > (be careful with that, it's just a quick hack!)
> >
> > Pros:
> > Mounting of the whole vserver mount tree happens using host tools.
> > No / overlay mount.
> > Namespace is completely clean, not even the rootfs mount is there.
> > chdir("..") trick is not possible (dunno about fd exchange).
> > Should be easy to integrate with the current alpha tools.
> >
> > Cons:
> > chroot(1) must not be on a separate partition.
> > Once inside the namespace currently there's no access to the host's
> > binaries (i'm working on that, maybe i can do something with
> > vc_set_namespace/vc_enter_namespace...)
> > [whatever you dislike about it/i missed]
> >
>
> HUGE con:
> It seems to create stale mounts that are completely out of reach and
> cannot be unmounted without a reboot. The problem is this:
> mount -n --bind $2 $2
> cd $2
> umount -n -l $2
> mount -n -t proc none tmp
>
> after cd $2 our pwdmnt is the bind'ed mount. Then that mount is
> unmounted. It is instantly detached and thus there's no reference to it
> in the namespace anymore. Once we change our pwd above that mount, it's
> out of reach. Normally, it would be unmounted now and everything's fine.
> But in our case, we mount something below this unreachable mount. Thus
> the mount is busy and can't be unmounted after we left it.
> So we lost any reference to the bind mount and to the proc mount on the
> bind mount and so we have no way to unmount it.
> Even if we do this in another namespace, the stale mounts will never go
> away, since on namespace destruction, mounts are searched starting from
> the root mount, and from there no way leads to our problematic mounts.
>
> Question: Could this be considered a kernel bug? I'd say the kernel
> should take care so that you're unable to create such a situation.
somehow I can hear Al's comment:
"if you use vfsmagic you better know what you are doing."
and yes, it is probably a kernel issue ...
best,
Herbert
> Bjoern
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver