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

Bug #1438942 reported by Tyler Hicks
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
schroot (Debian)
Fix Released
Unknown
schroot (Ubuntu)
Fix Released
High
Tyler Hicks

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.

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Changed in schroot (Ubuntu):
importance: Undecided → High
Revision history for this message
Michał Sawicz (saviq) wrote :

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.

Scott Moser (smoser)
Changed in schroot (Ubuntu):
status: New → Confirmed
Revision history for this message
Cris Dywan (kalikiana) wrote :

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

Revision history for this message
Michał Sawicz (saviq) wrote :

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)
Changed in schroot (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Tyler Hicks (tyhicks)
Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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.

Revision history for this message
Tyler Hicks (tyhicks) wrote :

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)

no longer affects: sbuild (Ubuntu)
Changed in schroot (Debian):
status: Unknown → New
Tyler Hicks (tyhicks)
Changed in schroot (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in schroot (Ubuntu):
status: Fix Committed → Fix Released
Changed in schroot (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.