Host's /dev/shm is mounted over when entering 14.10 and older sbuild schroots

[Tyler Hicks]

Originally reported by Scott Moser:

 https://bugs.launchpad.net/ubuntu/+source/click/+bug/1427264/comments/12

On a Vivid system with schroot 1.6.10-1ubuntu1, the host's /dev/shm is mounted over with a new tmpfs instance when entering a 14.10 and older schroot. It does not happen when entering a Vivid schroot.

# Create 14.10 and Vivid sbuild schroots
$ arch=amd64
$ for rel in vivid utopic; do mk-sbuild --eatmydata --arch=$arch $rel 2>&1 | tee /tmp/schroot-$rel-$arch.log; done

# Enter vivid-amd64 sbuild schroot and diff /proc/self/mounts
$ mounts=/proc/self/mounts
$ orig=$(mktemp) && cp $mounts $orig && schroot -c vivid-amd64 true; diff -u $orig $mounts

# Enter utopic-amd64 sbuild schroot and diff /proc/self/mounts
$ orig=$(mktemp) && cp $mounts $orig && schroot -c utopic-amd64 true; diff -u $orig $mounts
--- /tmp/tmp.DdnrDnkS2B 2015-03-31 18:19:51.406526006 -0500
+++ /proc/self/mounts 2015-03-31 18:19:51.818526006 -0500
@@ -28,3 +28,4 @@
 tmpfs /run/user/108 tmpfs rw,nosuid,nodev,relatime,size=101688k,mode=700,uid=108,gid=117 0 0
 gvfsd-fuse /run/user/108/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=108,group_id=117 0 0
 tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=101688k,mode=700,uid=1000,gid=1000 0 0
+tmpfs /dev/shm tmpfs rw,relatime 0 0

# Verify that /proc/self/mounts now contains two /dev/shm mounts
$ grep /dev/shm $mounts
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0

This causes a problem for programs that keep state in /dev/shm. For example, ecryptfs-utils maintains a per-user session counter in /dev/shm that is lost when a new tmpfs mount is performed on top of the old tmpfs mount. This results in encrypted home directories being unmounted when the schroot is tore down.

[Tyler Hicks (tyhicks)]

Note that this extra tmpfs mount happens with or without the use of encrypted home. It is more noticeable with encrypted home, since the encrypted home directory is unmounted.

[Michał Sawicz (saviq)]

I had the same problem before, but I had an explicit /dev/shm mount in /etc/schroot/sbuild/fstab, not sure where it came from really. Removing that fstab entry made the issue go away.

[Christian Dywan (kalikiana)]

I have the same /dev/shm mount so it's apparently normal. Unfortunately removing that didn't resolve the problem, I'm struggling to create a new chroot now because it always fails before it's finished and unmounts my home (luckily it's trivial to remount).

[Michał Sawicz (saviq)]

Yeah it seems the default fstab from sbuild includes /dev/shm. Talk to mterry about the home issue, he's had it I believe.

[Tyler Hicks (tyhicks)]

I looked at this some more today and I've figured out the cause. Before schroot performs the mounts inside of the container, based on the profile's fstab, it attempts to resolve all symlinks in the target path. Here's the problematic line in the sbuild fstab:

  tmpfs /dev/shm tmpfs defaults 0 0

It takes "/dev/shm/" and appends it to the chroot's source or session path, which results in something like "/var/lib/schroot/chroots/utopic-amd64/dev/shm". It then uses realpath(3) to resolve all of the symlinks so that if "/dev/shm" inside of the container pointed at "/run/shm", it would do the mount at "/var/lib/schroot/chroots/utopic-amd64/run/shm".

However, the combination of a Vivid or newer host and a Utopic or older chroot causes problems. Here are the symlinks involved:

/var/lib/schroot/chroots/utopic-amd64/dev/shm -> /run/shm
/run/shm -> /dev/shm

So realpath(3) is going to return "/dev/shm/", which results in tmpfs being mounted at the *host's* /dev/shm path.

[Tyler Hicks (tyhicks)]

I think what should happen is that instead of using realpath(3), schroot needs to use readlink(2) and then append the result of that to the base chroot path and then attempt to call readlink(2) on that path. That would result in symlinks only being resolved inside of the chroot instead of having a symlink that can point to outside of the chroot.

[Tyler Hicks (tyhicks)]

I've sent patches to fix this issue to upstream schroot by attaching the patches to a comment in a related Debian bug. I've linked this bug to that Debian bug. (https://bugs.debian.org/728096)

[Launchpad Janitor (janitor)]

This bug was fixed in the package schroot - 1.6.10-2ubuntu1

---------------
schroot (1.6.10-2ubuntu1) yakkety; urgency=low

  * Merge from Debian unstable. Remaining changes:
    - overlayfs-v1-workdir-support.patch: handle v3.18 backwards compatible v1
      mode workdir requirement. (LP: #1398523)
    - mount-make-bind-mounts-private.patch: Make bind mounts use private mount
      propagation, to avoid recursive bind mounts in the schroot spilling over
      into the host and unmounting them on the host when tearing down the
      schroot. (LP: #1430557, Closes: #786566)
  * Dropped changes:
    - overlayfs: handle v3.18 overlay union type. (LP: #1398569)
      + A patch with equivalent functionality was included by Debian
  * resolve-mount-dest-while-chrooted.patch: Resolve mount destination paths
    only after calling chroot() to avoid accidentally mounting filesystems
    in the host. (LP: #1438942, Closes: #728096)

 -- Tyler Hicks <email address hidden> Wed, 27 Apr 2016 16:41:56 -0500