[buildd-tools-devel] Bug#728096: schroot fails if shm tmpfs is mounted on /dev/shm

[Tyler Hicks]

Package: schroot
Followup-For: Bug #728096

Users have hit this issue in Ubuntu, too. I've triaged it and have
determined that Laurent is correct in Message #17 that the schroot mount
helper is using the host's filesystem to resolve symlinks in the chroot.

It is simply calling realpath(3) on the mount destination in the chroot,
from a process that is not chrooted, so realpath(3) is going to use the
host filesystem to resolve symlinks such as
'/<chroot>/dev/shm -> /run/shm'. It then tries to fixup the final
resolved path but appended the chroot basepath but it's too late at that
point, the host's filesystem has already been used to resolve the
symlink target.

We're actually getting filesystems mounted in the host filesystem in
Ubuntu (LP: #1438942) due to /run/shm existing in the host and pointing
back to /dev/shm.

Here's a simple test:

  # Show that schroot's mount binary is using the host fs to resolve symlinks
  $ mkdir -p /tmp/bug728096/dev
  $ mkdir -p /tmp/bug728096/run/shm
  $ ln -s /run/shm /tmp/bug728096/dev/shm
  $ ls -ld /{dev,run}/shm
  drwxrwxrwt 2 root root 120 Jul 29 14:07 /dev/shm
  lrwxrwxrwx 1 root root   8 Jul 29 14:07 /run/shm -> /dev/shm
  $ ls -ld /tmp/bug728096/{dev,run}/shm
  lrwxrwxrwx 1 tyhicks tyhicks    8 Jul 29 14:49 /tmp/bug728096/dev/shm -> /run/shm
  drwxrwxr-x 2 tyhicks tyhicks 4096 Jul 29 14:49 /tmp/bug728096/run/shm
  $ echo "tmpfs /dev/shm/ tmpfs defaults 0 0" > /tmp/fstab
  $ grep /dev/shm /proc/mounts
  tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
  $ sudo ./libexec/mount/mount -v -f /tmp/fstab -m /tmp/bug728096
  $ grep /dev/shm /proc/mounts
  tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
  tmpfs /dev/shm tmpfs rw,relatime 0 0
  
  # Now reproduce Laurent's original bug report by removing the host's /run/shm
  $ sudo umount /dev/shm
  $ sudo rm /run/shm
  $ sudo ./libexec/mount/mount -v -f /tmp/fstab -m /tmp/bug728096
  E: boost::filesystem::create_directory: File exists: "/tmp/bug728096/dev/shm"
  $ echo $?
  1

I've attached fixes for the master and 1.6 schroot branches. They fork
off a process that changes root to the chroot base path before calling
realpath(3) on the mount destination.

Note that I'm still pretty confused by a part of the code in
resolve_path_chrooted() (which is mostly the old resolve_path()). I
don't understand the what is happening after the
"// Try validating the parent directory." comment but I left it since I
couldn't wrap my head around it. Any insight to what it is doing and
whether we can remove it now?

Tyler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: master-libexec-mount-Resolve-mount-destinations-while-chroo.patch
Type: text/x-diff
Size: 10500 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20150729/f6de1104/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: schroot-1.6-schroot-mount-Resolve-mount-destinations-while-chroo.patch
Type: text/x-diff
Size: 9959 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20150729/f6de1104/attachment-0003.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20150729/f6de1104/attachment-0001.sig>