Re: [lmi] Missing system directories in chroot [Was: Creating a chroot for cross-building lmi]

[Vadim Zeitlin]

On Fri, 16 Sep 2016 17:24:22 +0000 Greg Chicares <address@hidden> wrote:

GC> So...can I say that in my chroots, I'm running a "jessie" userland on
GC> an underlying "wheezy" kernel?

 Yes, of course. There is no virtualization involved in using a chroot, the
underlying kernel is exactly the same.

GC> If that's the case, then I can see how it might work as long as the
GC> releases are close. But if I were to try this with a "potato" kernel,
GC> might it fail because the "jessie" userland requires services that an
GC> ancient kernel lacks?

 Yes, it's possible in theory, but in practice most things will work with a
rather wide range of kernels. But I'm pretty sure that e.g. systemd
wouldn't work with an ancient kernel without cgroups support.

GC> > GC> I rebooted). I wasn't expecting a command executed in the chroot to
GC> > GC> have any effect on the underlying OS's mounts: I thought "what happens
GC> > GC> in a chroot, stays in the chroot",
GC> > 
GC> >  This is true in the sense that nothing outside of chroot in the file
GC> > system can be modified, but definitely not true generally speaking.
GC> 
GC> And it's not rigorously true even in the limited sense of your first
GC> clause, as I found out when I executed 'sudo rm /dev/shm' inside a
GC> chroot.

 Sorry for doubting you, but I still think that this is actually
impossible. Symlinks inside the chroot can't be used to affect anything
outside of it. Hard links can, of course, but hard links for directories
are very unusual (and under Linux bind mounts are a safer and better way of
achieving the same effect). I'm willing to eat my (non-existent) hat if you
can provide a reproducible way of affecting the host system from inside
chroot without using either hard links or bind mounts.

GC> > you could modify your routing table from inside chroot and break 
networking
GC> > on the host system. This is, in fact, one of the driving ideas behind
GC> > cgroups and the newfangled software using them such as Docker or systemd:
GC> > they promise (and deliver, AFAIK) much better degree of isolation.
GC> 
GC> Or OpenVZ.

 I didn't want to confuse things further by mentioning more alternatives,
especially this one because I believe it's obsolete and was replaced by
LXC. But I do admit I always felt strangely partial to this one.

GC> I still know far too little about linux, but this is apparently some IPC
GC> thing, and I don't imagine I'm going to need it. I'm guessing that if
GC> 'chrome' works, then that's more than enough for lmi development.

 I ran lmi inside a simple chrooted environment many times and without any
apparent problems, so I definitely hope it should be.

 Just to conclude this discussion, if you really want to have a fully
isolated, VM-like, Linux system, then LXC is probably the way to go. As for
Docker, it could be used to make a container containing lmi and everything
it needs and allowing to run it on any recent Linux system, including
RedHat ones.

 Regards,
VZ