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

[Greg Chicares]

On 2016-09-16 17:45, Vadim Zeitlin wrote:
> On Fri, 16 Sep 2016 17:24:22 +0000 Greg Chicares <address@hidden> wrote:
[...]
> 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.

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

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728096#17
| Is it possible that schroot is actually trying to resolve the /dev/shm
| -> /run/shm symlink outside of the chroot?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728096#34
| Users have hit this issue in Ubuntu, too. I've triaged it and have
| determined that Laurent is correct in Message #17 that the schroot mount
| helper is using the host's filesystem to resolve symlinks in the chroot.
|
| It is simply calling realpath(3) on the mount destination in the chroot,
| from a process that is not chrooted, so realpath(3) is going to use the
| host filesystem to resolve symlinks such as
| '/<chroot>/dev/shm -> /run/shm'. It then tries to fixup the final
| resolved path but appended the chroot basepath but it's too late at that
| point, the host's filesystem has already been used to resolve the
| symlink target.
|
| We're actually getting filesystems mounted in the host filesystem in
| Ubuntu (LP: #1438942) due to /run/shm existing in the host and pointing
| back to /dev/shm.

He then provides a series of about one dozen shell commands that
reproduce the defect originally reported.

This appears to be the same problem:
  https://github.com/codelibre-net/schroot/pull/20
and this definitely is:
  https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1438942
AFAICT, ubuntu fixed it on 2016-04-28, but it seems to remain open
in debian and upstream.

>  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.

Soon we'll try cross-compiling with redhat, and if that turns out to be
arduous (either technically, or politically, or both), then a container
might be the best answer. In that case, would you prefer LXC to docker?