lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Missing system directories in chroot [Was: Creating a chroot f


From: Vadim Zeitlin
Subject: Re: [lmi] Missing system directories in chroot [Was: Creating a chroot for cross-building lmi]
Date: Fri, 16 Sep 2016 22:52:21 +0200

On Fri, 16 Sep 2016 20:39:11 +0000 Greg Chicares <address@hidden> wrote:

GC> I'm willing to accept that what I observed is impossible as long as
GC> 'schroot' is free of defects. But it is not--it "is using the host's
GC> filesystem to resolve symlinks in the chroot":

 I am not sure if it's worth delving into these bug reports, but, at the
risk of seeming stubborn, I don't think any defect with symlinks in schroot
could allow code running inside a chroot to escape from it -- this would
only be possible due to a (horrible) bug in the kernel and I definitely
haven't heard about anything like this.

GC> This appears to be the same problem:
GC>   https://github.com/codelibre-net/schroot/pull/20
GC> and this definitely is:
GC>   https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1438942

 These bugs seems to say that due to some symlink-related bug, schroot
mounts tmpfs at a wrong mount point. This is perfectly possible, of course,
all I was saying is that whatever schroot does, you can't affect the host
system by doing anything with a symlink inside a chroot.


GC> >  Just to conclude this discussion, if you really want to have a fully
GC> > isolated, VM-like, Linux system, then LXC is probably the way to go. As 
for
GC> > Docker, it could be used to make a container containing lmi and everything
GC> > it needs and allowing to run it on any recent Linux system, including
GC> > RedHat ones.
GC> 
GC> Soon we'll try cross-compiling with redhat, and if that turns out to be
GC> arduous (either technically, or politically, or both), then a container
GC> might be the best answer. In that case, would you prefer LXC to docker?

 They're useful for different things. LXC is a lightweight KVM replacement
and can be used in the same way as full-fledged virtual machines (except it
uses the same kernel, of course, so you can't be running MSW or OS/2 using
LXC) while Docker is something quite different and is more useful for
distributing/deploying individual applications.

 So the choice depends on what exactly you'd like to do and it's even
possible that both could be useful: LXC for setting up a development
environment for working on lmi and Docker for distributing the pre-built
version of lmi to other systems.

 I hope this explains it, but please let me know if you have more
questions,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]