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

[Vadim Zeitlin]

On Fri, 16 Sep 2016 00:41:47 +0000 Greg Chicares <address@hidden> wrote:

GC> (1) What does the second "devpts" mean?
GC>   mount -t devpts devpts /dev/pts
GC>            FIRST  SECOND
GC> I understand that '-t devpts' specifies the mount type, and that here
GC> "devpts" is a suboption of '-t', just as "ext4" is. I understand that
GC> '/dev/pts' is the directory where this filesystem of type "devpts" is
GC> mounted. But is the second "devpts" the name of an actual device? or
GC> is it an arbitrary word, such as `man mount` says is used when 'proc'
GC> is mounted?

 Yes, exactly: "mount -t devpts foobar /dev/pts" would have worked just as
well. And I agree it's confusing, I should have mentioned this.

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?

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

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.

GC> Anyway...now I have /proc and /dev/pts mounted, but when I try running
GC> chrome I get this:
GC> 
GC> $/usr/bin/google-chrome-stable
GC> [9724:9741:0916/001015: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> [9724:9724:0916/001015:ERROR:shared_memory_posix.cc(290)] Creating shared 
memory in /dev/shm/.com.google.Chrome.vrvocU failed: Permission denied
GC> [9724:9724:0916/001015:ERROR:shared_memory_posix.cc(293)] Unable to 
access(W_OK|X_OK) /dev/shm: Permission denied
GC> [9724:9724:0916/001015:FATAL:shared_memory_posix.cc(295)] This is 
frequently caused by incorrect permissions on /dev/shm.  Try 'sudo chmod 1777 
/dev/shm' to fix.
GC> zsh: abort      /usr/bin/google-chrome-stable
GC> 
GC> ...so I change permissions as suggested...
GC> 
GC> $sudo chmod 1777 /dev/shm

 FWIW I can confirm that /dev/shm in my chroot also has 755 permissions,
while it does use 1777 on the main system. Not sure who/when exactly set up
these permissions.

GC> ...and now chrome seems to work as it should--kind of like iceweasel,

 OT, but it's back to being called Firefox in Debian now.

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

 Regards,
VZ