touch-packages team mailing list archive

[Tyler Hicks <tyhicks@xxxxxxxxxxxxx>]

The issue is around mount propagation. The /home/ directory is being
recursively bound into the schroot tree. When the schroot tree is
recursively unmounted and SCHROOT_DIR/home/foo is unmounted, that
unmount event is being propagated to the original /home/foo mount point.
To prevent that from happening, the recursively bound SCHROOT_DIR/home
mount point needs to be recursively private. Using the example in
comment #4, with eCryptfs instead of ext4, that would look like this:

foo@sec-vivid-amd64:~$ grep home/foo /proc/mounts
/home/foo/.Private /home/foo ecryptfs rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=176339c8321afc83,ecryptfs_sig=35e81f7d08221a22,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0
foo@sec-vivid-amd64:~$ sudo mount -R /home /tmp/home
foo@sec-vivid-amd64:~$ sudo mount --make-rslave /tmp/home
foo@sec-vivid-amd64:~$ grep home/foo /proc/mounts
/home/foo/.Private /home/foo ecryptfs rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=176339c8321afc83,ecryptfs_sig=35e81f7d08221a22,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0
/home/foo/.Private /tmp/home/foo ecryptfs rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=176339c8321afc83,ecryptfs_sig=35e81f7d08221a22,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0
foo@sec-vivid-amd64:~$ sudo umount -R /tmp/home
foo@sec-vivid-amd64:~$ grep home/foo /proc/mounts
/home/foo/.Private /home/foo ecryptfs rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=176339c8321afc83,ecryptfs_sig=35e81f7d08221a22,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0

Note that two separate mount commands are required. The -R and --make-
rslave options cannot be specified in the same mount command. The
mount(8) program will turn this into two mount(2) syscalls and strip the
MS_REC flag off of the first mount(2) syscall, resulting in a non-
recursive bind mount:

mount("/home", "/tmp/home", 0x1880f30, MS_MGC_VAL|MS_BIND, NULL) = 0
mount("none", "/tmp/home", NULL, MS_REC|MS_SLAVE, NULL) = 0

This means that we can add a new line to the click/fstab file,
specifying that the schroot's /home/ recursive bind mount point should
be made recursively private. While I haven't had a chance to do
extensive testing, the following change seems to fix this bug:

$ diff -Nurp /etc/schroot/click/fstab.orig /etc/schroot/click/fstab
--- /etc/schroot/click/fstab.orig	2015-03-12 15:23:37.631296891 -0500
+++ /etc/schroot/click/fstab	2015-03-12 15:24:09.183296891 -0500
@@ -8,5 +8,6 @@
 /dev            /dev            none    rw,bind         0       0
 /dev/pts        /dev/pts        none    rw,bind         0       0
 /home           /home           none    rw,rbind        0       0
+none            /home           none    rslave          0       0
 /tmp            /tmp            none    rw,bind         0       0
 /run/shm        /run/shm        none    rw,bind         0       0


** Changed in: click (Ubuntu)
       Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1427264

Title:
  using ecryptfs, creating frameworks fail to bind mount issues

Status in click package in Ubuntu:
  Triaged

Bug description:
  Using vivid creating framework fails for ecryptfs users, the issue is
  similar to bug #769595

  The userdir is mounted in a way which makes unmounts fail

  "E: 10mount: umount: /var/lib/schroot/mount/click-ubuntu-sdk-14.10
  -armhf-ec6aaf62-31e0-47e9-b2f8-73f0b038fb4d/home/user: target is busy
  E: 10mount: (In some cases useful info about processes that E:
  10mount: use the device is found by lsof(8) or fuser(1).) "

  changing the fstab line to be "/home/user /home/user      none
  rw,bind        0       0" workarounds the issue

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