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

[Greg Chicares]

On 2016-09-16 15:37, Vadim Zeitlin wrote:
> On Fri, 16 Sep 2016 00:41:47 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> (2) The mount appears to be persistent. I expected that running
> GC>   mount -t devpts devpts /dev/pts
> GC> within the chroot would have an effect only within that chroot session,
> GC> and that exiting the chroot would cause the mount to disappear.
> 
>  I wouldn't expect this to happen. Mount modifies the kernel mount table
> and the main system and chroot share the same kernel, so why should it
> disappear?

First of all, thanks for reading this. I figure that if I can explain how
my conclusions logically follow from my preconceptions, you can point out
where I've gone astray. So...can I say that in my chroots, I'm running a
"jessie" userland on an underlying "wheezy" kernel? If that's the case,
then I can see how it might work as long as the releases are close. But
if I were to try this with a "potato" kernel, might it fail because the
"jessie" userland requires services that an ancient kernel lacks?

> GC> I rebooted). I wasn't expecting a command executed in the chroot to
> GC> have any effect on the underlying OS's mounts: I thought "what happens
> GC> in a chroot, stays in the chroot",
> 
>  This is true in the sense that nothing outside of chroot in the file
> system can be modified, but definitely not true generally speaking.

And it's not rigorously true even in the limited sense of your first
clause, as I found out when I executed 'sudo rm /dev/shm' inside a
chroot.

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

Or OpenVZ. You should have trademarked that. You might want to
register "FreeVZ" while it's still available.

> GC> I suppose I should add "nosuid,noexec" to the chroot's /dev/pts mount,
> GC> so that it's no less restrictive than the underlying OS's mount.
> 
>  Yes, this looks like a good idea. Although as long as you trust software
> running inside chroot, it's not exactly indispensable.

I thought maybe a "directory" schroot would take care of that...

[chroot]$mount
/proc on /proc type proc (rw)

[host]$mount |grep devpts
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
devpts on /srv/chroot/chrome/dev/pts type devpts 
(rw,relatime,mode=600,ptmxmode=000)
devpts on 
/var/lib/schroot/mount/chrome-b2984c44-01cb-4f77-9887-ff9be97697ed/dev/pts type 
devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)

...but it doesn't seem to; maybe that's just an arguable defect in schroot.
I'm guessing that 'chrome' creates its own "sandbox" more cautiously (on
the last line above, which does use "nosuid,noexec").

> GC> $/usr/bin/google-chrome-stable
> GC> [11011:11029:0916/002915:ERROR:bus.cc(434)] Failed to connect to the bus: 
> Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or 
> directory
> GC> 
> GC> (google-chrome-stable:11011): GConf-WARNING **: Client failed to connect 
> to the D-BUS daemon:
> 
>  I don't know if you can share the same D-BUS daemon between the main
> system and chroot or if you need to run another instance of it just inside
> chroot. The latter would seem to be better from isolation point of view...

I'm still getting those error messages, even with my "directory" schroot.

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