[Lxc-users] lxc-execute and isolation approaches

[Serge Hallyn]

Quoting Vladimir (ml at foomx.de):
> On Sun, 5 May 2013 18:26:01 +0100
> Ben Butler-Cole <ben at bridesmere.com> wrote:
> 
> > Hello Vladimir
> > 
> > The files that the process can access should be it's own copy of a
> > complete Linux filesystem, rather than the filesystem of the host.
> > From the host you should be able to see that filesystem
> > at /var/lib/lxc/testcase/rootfs.
> > 
> > Is that not the case for you?
> > 
> > Perhaps I have misunderstood your question.
> > 
> > -Ben
> 
> If I understood it correctly application container created via
> lxc-execute don't have a rootfs like a "full" container has. Also I
> don't see it under /var/lib/lxc...

What would you expect to see under /var/lib/lxc?

> In the example you see that afer I still can see and access the
> file /tmp/foo. Further on in the container I just could type "reboot"
> and the host system would reboot.

You haven't defined a network, so your container is using the host's
network.  You haven't defined a private /dev, so you're using the
host's /dev.  If you're using sysvinit or systemd, you can reboot
bc you can talk to /dev/initctl.  If upstart, you are talking to
the host's upstart over an abstract unix socket.

> root at server:~
> #> touch /tmp/foo
> root at server:~
> #> ls -l /tmp/foo 
> -rw------- 1 root root 0 2013-05-05 22:27 /tmp/foo
> root at server:~
> #> lxc-execute -n testcase -f lxc.conf /bin/bash
> root at testcase:~
> #> ls -l /tmp/foo 
> -rw------- 1 root root 0 2013-05-05 22:27 /tmp/foo

If you mount --bind /tmp /mnt, you'll see that that is not reflected
on the host.  You have a private mount table, that is all.