From: Björn Steinbrink (bjoern.steinbrink_at_isp4p.net)
Date: Fri 05 Nov 2004 - 11:03:21 GMT
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.
Bjoern
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver