[Bug 1438942] Re: Host's /dev/shm is mounted over when entering 14.10 and older sbuild schroots

[Launchpad Bug Tracker]

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 <tyhicks at canonical.com>  Wed, 27 Apr 2016 16:41:56 -0500

** Changed in: schroot (Ubuntu)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to schroot in Ubuntu.
https://bugs.launchpad.net/bugs/1438942

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

Status in schroot package in Ubuntu:
  Fix Released
Status in schroot package in Debian:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1438942/+subscriptions