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

[Greg Chicares]

On 2016-09-16 23:22, Vadim Zeitlin wrote:
> On Fri, 16 Sep 2016 23:12:51 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> The issue I reported earlier was (commands in chronological order):
> GC> 
> GC>   [host]$ ls -l /dev/sh*
> GC>   lrwxrwxrwx 1 root root 8 Feb 16  2016 /dev/shm -> /run/shm
> GC> 
> GC>   [chroot]$ sudo rm /dev/shm
> GC> 
> GC>   [host]$ ls -l /dev/sh*
> GC>   zsh: no matches found: /dev/sh*
> GC> 
> GC> Isn't that perfectly consistent with the portion of debian bug 728096
> GC> quoted above...
> 
>  I still don't see how can this be possible :-( If /dev/shm is just a
> symlink, there is no way that removing it from inside chroot can affect the
> host file system. If it's a bind-mounted tmpfs file system, then destroying
> its contents would indeed affect the host, but removing the mount point
> itself still wouldn't do it.

Thank you for persistently disagreeing, because...

>  The only possibility I see is that schroot bind-mounts /dev itself. This
> would explain the above, but does it really do this?

Yes.

$head -8 /etc/schroot/default/fstab
# fstab: static file system information for chroots.
# Note that the mount point will be prefixed by the chroot path
# (CHROOT_PATH)
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/proc           /proc           none    rw,bind        0       0
/sys            /sys            none    rw,bind        0       0
/dev            /dev            none    rw,bind         0       0

As the "#" comments say, <mount point> is prefixed by chroot path, so this:
  /dev /dev none rw,bind 0 0
means:
  /dev $CHROOT/dev none rw,bind 0 0
exactly as you said, for "directory" chroots. But not "plain" chroots.

This pitfall is documented in `man schroot.conf`:
| setup.fstab ... Also note that mountpoints are canonicalised on
| the host, which will ensure that absolute symlinks point inside
| the chroot, but complex paths containing multiple symlinks may
| be resolved incorrectly; it is inadvisable to use nested
| symlinks as mountpoints.

So a "plain" schroot does no setup, but it's missing some directories
that may be important; while a "directory" schroot does everything we
might want, but much more that we don't want (like binding /home, and
copying /etc/passwd so that the schroot has all the system users like
'uucp', 'usbmux', and 'libvirt-qemu').

Thus...

On 2016-09-16 17:45, Vadim Zeitlin wrote:
> 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 was insisting that I had set up no hard links or bind mounts, but
in fact I had, implicitly, when I used a "directory" schroot.

Anyway, in forthcoming updates to 'README.schroot' I plan to use a
"plain" chroot as long as it works. We've already figured out how to
solve some potential problems (e.g., by mounting /dev/pts and /proc ),
and now a "plain" chroot seems to work perfectly well for the very
limited task of cross-building lmi, which is all we really need it for.
The "plain" type is less complex and provides much better isolation.

BTW, I tried making a "plain" debian 'sid' chroot in a similar way, but
that seems not to work, at least not without further tweaking:
  (sid)address@hidden:/# apt-get update
  Get:1 http://ftp.us.debian.org/debian sid InRelease [209 kB]
  Get:2 http://ftp.us.debian.org/debian sid/main i386 Packages [7194 kB]
  Get:3 http://ftp.us.debian.org/debian sid/main Translation-en [5476 kB]
  Fetched 12.9 MB in 15s (838 kB/s)
  Reading package lists... Done
  W: No sandbox user '_apt' on the system, can not drop privileges
but I just mention that in passing: I'm not even going to look into that
"W:" message, which is explained here:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806475
because I don't see any need for 'sid' today, and I've had an exhausting
day fixing other issues, like...

  https://lists.debian.org/debian-boot/2014/11/msg00381.html
[debootstrap fails with:
  E: Invalid Release signature (key id 8B48AD6246925553)
where everything except the last eight bytes of the genuine key got
truncated; the workaround is to repeat the debootstrap command until it
works]

Oh, and if .git/config contains
  [remote "origin"]
    url = git://git.savannah.nongnu.org/lmi.git
instead of "address@hidden:/srv/git/lmi.git", and ~/.ssh/ contains only
DSA keys that savannah no longer accepts, then every git command except
'push' will work, but 'push' will give "connection reset by peer".

I figure that if I don't mention those problems here where they're easy
to search for, then someday I'll have them again and won't remember how
to fix them. I don't want to say how much time I spent trying to get
'git push' to work, largely because I assumed it was an schroot problem.