/dev/shm inconsistency in chroot

[Sree Harsha Totakura]

Hi,

It has been known for a while that any access to /dev/shm fails inside
chroot if the host system has /dev/shm symlinked to /run/shm.

The suggested method to deal with this until now is to remove the
symlink from the host system, create /dev/shm directory and mount a
tmpfs on it.

I spent sometime investigating why this is needed and here are some
points I noted: from libstore/build.cc the daemon tries to bind mount
some paths from the host system into the chroot directory.  Among these
are /dev and /dev/pts.  The daemon also mounts a tmpfs file system under
chrootdir+/dev/shm should the path /dev/shm exist.

Due to bind mounting /dev, on systems where /dev/shm is a symlink, the
symlink is also present in the chrootdir+/dev.  Since the symlink points
to /run/shm, and since /run is not bind mounted by default into the
chrootdir+/run, the symlink is broken inside chroot.

The above problem can be addressed by passing --chroot-directory=/run to
the guix-daemon which then includes /run into the list of mounts that
are to be bind mounted inside chroot.  This will resolve the
chroot+/dev/shm symlink properly.  Yet, the accesses to /dev/shm fail
inside the chroot.  This is because the mount statement in build.cc for
mounting tmpfs at chroot+/dev/shm mounts the tmpfs at /run/shm the
target of the symlink and since /run tree is made private the mount does
not propagate into the bind mounted chroot+/run tree.  In the chroot,
this leaves the /dev/shm symlink to point to the directory /run/shm and
obviously any shared memory accesses fail.

This problem can be fixed finally by passing
--chroot-directory=/run/shm.  Although the tmpfs mount for
chroot+/dev/shm still ends up mounting tmpfs at /run/shm, since /run/shm
is now bind mounted to chroot+/run/shm, inside the chroot the symlink
/dev/shm points to /run/shm which is now a tmpfs.  The shared memory
accesses work fine here.  However there is caveat: since /run/shm is
bindmounted any files from the host system from that directory are also
present in the chroot.

To address this further and to get rid of having the user to pass
--chroot-directory flag, I propose the attached patch.

Regards,
Sree

0001-Create-tmpfs-on-dev-shm-after-chrooting.patch
Description: Text Data

signature.asc
Description: OpenPGP digital signature