Bug#728096: schroot fails if shm tmpfs is mounted on /dev/shm
On 2015-07-29 15:36:42, Tyler Hicks wrote: > 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? Ping. I had another Ubuntu user hit this bug today. I'm wanting to push the fix before Ubuntu 16.04 is released but I'd prefer some feedback on the patch before then. Thanks! Tyler signature.asc Description: PGP signature
Bug#728096: schroot fails if shm tmpfs is mounted on /dev/shm
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
'//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 tyhicks8 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
From 86a39d878bc1b6ea59b4f354f03b635014b720a1 Mon Sep 17 00:00:00 2001
From: Tyler Hicks
Date: Tue, 28 Jul 2015 02:11:07 -0500
Subject: [PATCH] libexec-mount: Resolve mount destinations while chrooted
The mount binary was attempting to use realpath(3) from outside of the
chroot to resolve mount destination paths inside of the chroot. It would
then take the resolved path and prepend it with the path to the chroot
in an attempt to enforce that symlink resolution will always end up
inside of the chroot.
One example of why this approach isn't sufficient is that when
//dev/shm/ is the mount destination but it is a symlink to
/run/shm and the host's /run/shm is a symlink to /dev/shm. The resolved
path will end up being //dev/shm/ and, due to mount following
symlinks, the host's /dev/shm will be mounted over.
To fix the path resolution issue, this patch first resolves the path to
the chroot base path, then forks and calls chroot(2) on that path, then
resolves the path to the mount destination inside the chroot. Finally,
the resolved chroot base path and the resolved mount destination path
are combined to create the fully resolved path used for mounting.
Bug-Debian: https://bugs.debian.org/728096
Bug-Ubuntu: https://launchpad.net/bugs/1438942
Signed-off-by: Tyler Hicks
---
libexec/mount/main.cc | 141 ++
libexec/mount/main.h | 28 --
2 files changed, 141 insertions(+), 28 deletions(-)
diff --git a/libexec/mount/main.cc b/libexec/mount/main.cc
index 9ea6e80..bbf4a18 100644
--- a/libexec/mount/main.cc
+++ b/libexec/mount/main.cc
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -53,8 +54,14 @@ namespace schroot
{
{bin::schroot_mount::main::CHILD_FORK, N_("Failed to fork child")},
{bin::schroot_mount::main::CHILD_WAIT, N_("Wait for child failed")},
+// TRANSLATORS: %1% = directory
+{bin::schroot_mount::main::CHROOT, N_("Failed to change root to directory ‘%1%’")},
+{bin::schroot_mount::main::DUP,N_("Failed to duplicate file descriptor")},
// TRANSLATORS: %1% = command name
{bin::schroot_mount::main::EXEC, N_("Failed to execute “%1%”")},
+{bin::schroot_mount::main::PIPE, N_("Failed to create pipe")},
+{bin::schroot_mount::main::POLL, N_("Failed to poll file descriptor")},
+{bin::schroot_mount::main::READ, N_("Failed to read file
Bug#728096: [buildd-tools-devel] Bug#728096: schroot fails if shm tmpfs is mounted on /dev/shm
Hi Roger, I am running into the same problem here, trying to setup a wheezy build environment. > Note that the "-v" option will make schroot log all mount operations > during session creation, and umount operations during cleanup. I'd > recommend running with this to debug what's going on. Here you go: torsten@pulsar:~$ schroot -v -c wheezy-amd64 I: Executing ‘00check setup-start ok’ I: 00check: STAGE=setup-start I: 00check: STATUS=ok I: 00check: AUTH_GID=1000 I: 00check: AUTH_HOME=/home/torsten I: 00check: AUTH_RGID=1000 I: 00check: AUTH_RGROUP=torsten I: 00check: AUTH_RUID=1000 I: 00check: AUTH_RUSER=torsten I: 00check: AUTH_SHELL=/bin/bash I: 00check: AUTH_UID=1000 I: 00check: AUTH_USER=torsten I: 00check: CHROOT_ALIAS=wheezy-amd64 I: 00check: CHROOT_DESCRIPTION=wheezy-amd64 (session chroot) I: 00check: CHROOT_DEVICE=/dev/vgsys/wheezy_amd64_chroot I: 00check: CHROOT_LVM_SNAPSHOT_DEVICE=/dev/vgsys/wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315 I: 00check: CHROOT_LVM_SNAPSHOT_NAME=wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315 I: 00check: CHROOT_LVM_SNAPSHOT_OPTIONS=--size 4G I: 00check: CHROOT_MOUNT_DEVICE=/dev/vgsys/wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315 I: 00check: CHROOT_MOUNT_LOCATION=/var/lib/schroot/mount/wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315 I: 00check: CHROOT_MOUNT_OPTIONS=-o noatime I: 00check: CHROOT_NAME=wheezy-amd64 I: 00check: CHROOT_PATH=/var/lib/schroot/mount/wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315 I: 00check: CHROOT_PROFILE=sbuild I: 00check: CHROOT_PROFILE_DIR=/etc/schroot/sbuild I: 00check: CHROOT_SESSION_CLONE=false I: 00check: CHROOT_SESSION_CREATE=false I: 00check: CHROOT_SESSION_PURGE=true I: 00check: CHROOT_TYPE=lvm-snapshot I: 00check: DATA_DIR=/usr/share/schroot I: 00check: LIBEXEC_DIR=/usr/lib/x86_64-linux-gnu/schroot I: 00check: MOUNT_DIR=/var/lib/schroot/mount I: 00check: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin I: 00check: PID=18402 I: 00check: PLATFORM=linux I: 00check: PWD=/ I: 00check: SESSION_ID=wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315 I: 00check: SETUP_CONFIG=/etc/schroot/sbuild/config I: 00check: SETUP_COPYFILES=/etc/schroot/sbuild/copyfiles I: 00check: SETUP_DATA_DIR=/usr/share/schroot/setup I: 00check: SETUP_FSTAB=/etc/schroot/sbuild/fstab I: 00check: SETUP_NSSDATABASES=/etc/schroot/sbuild/nssdatabases I: 00check: SYSCONF_DIR=/etc/schroot I: 00check: VERBOSE=verbose I: Executing ‘05btrfs setup-start ok’ I: Executing ‘05file setup-start ok’ I: Executing ‘05lvm setup-start ok’ E: 05lvm: Setting logging type to disk E: 05lvm: Setting chunksize to 4.00 KiB. E: 05lvm: Finding volume group "vgsys" E: 05lvm: Archiving volume group "vgsys" metadata (seqno 290). E: 05lvm: Creating logical volume wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315 E: 05lvm: Creating volume group backup "/etc/lvm/backup/vgsys" (seqno 291). E: 05lvm: activation/volume_list configuration setting not defined: Checking only host tags for vgsys/wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315 E: 05lvm: Creating vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315 E: 05lvm: Loading vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315 table (253:30) E: 05lvm: Resuming vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315 (253:30) E: 05lvm: Initializing 4.00 KiB of logical volume "vgsys/wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315" with value 0. E: 05lvm: Creating logical volume snapshot0 E: 05lvm: Creating vgsys-wheezy_amd64_chroot-real E: 05lvm: Loading vgsys-wheezy_amd64_chroot-real table (253:31) E: 05lvm: Loading vgsys-wheezy_amd64_chroot table (253:29) E: 05lvm: Creating vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315-cow E: 05lvm: Loading vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315-cow table (253:32) E: 05lvm: Resuming vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315-cow (253:32) E: 05lvm: Loading vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315 table (253:30) E: 05lvm: Suspending vgsys-wheezy_amd64_chroot (253:29) with filesystem sync with device flush E: 05lvm: Suspending vgsys-wheezy_amd64_chroot-real (253:31) with filesystem sync with device flush E: 05lvm: Loading vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315-cow table (253:32) E: 05lvm: Suppressed vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315-cow (253:32) identical table reload. E: 05lvm: Resuming vgsys-wheezy_amd64_chroot-real (253:31) E: 05lvm: Resuming vgsys-wheezy--amd64--6838bfa5--635a--41ee--a787--4f973109b315 (253:30) E: 05lvm: Resuming vgsys-wheezy_amd64_chroot (253:29) E: 05lvm: Creating volume group backup "/etc/lvm/backup/vgsys" (seqno 292). I: 05lvm: Logical volume "wheezy-amd64-6838bfa5-635a-41ee-a787-4f973109b315" created I: Executing ‘05union setup-start ok’ I: Executing ‘10mount setup-start ok’ I: 10mount: Mounting /dev/vgsy
Bug#728096: [buildd-tools-devel] Bug#728096: schroot fails if shm tmpfs is mounted on /dev/shm
On Mon, Nov 25, 2013 at 04:49:45PM +0100, Laurent Bigonville wrote: > Hi, > > To be even more clear: > > HOST: > bigon@soldur:~$ ls -ld /dev/shm /run/shm > ls: impossible d'accéder à /run/shm: Aucun fichier ou dossier de ce type > drwxrwxrwt. 2 root root 300 nov 25 16:05 /dev/shm > > CHROOT: > (sid-amd64-sbuild)root@soldur:/# ls -ld /dev/shm /run/shm > lrwxrwxrwx. 1 root root8 Nov 23 2012 /dev/shm -> /run/shm > drwxr-xr-x. 2 root root 4096 Nov 23 2012 /run/shm > > Creating /run/shm on the host is also fixing this. Sorry for the delayed reply; RSI has been limiting my activity for some time. > Is it possible that schroot is actually trying to resolve the /dev/shm > -> /run/shm symlink outside of the chroot? It's possible, but unlikely. The schroot-mount helper should ensure that all mountpoints are inside the chroot and that it's not a symlink which could redirect to a mountpoint outside. That condition should be fatal. Simply removing the /dev/shm link inside the chroot and making it a directory should make things work. Note that the "-v" option will make schroot log all mount operations during session creation, and umount operations during cleanup. I'd recommend running with this to debug what's going on. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728096: schroot fails if shm tmpfs is mounted on /dev/shm
Hi, To be even more clear: HOST: bigon@soldur:~$ ls -ld /dev/shm /run/shm ls: impossible d'accéder à /run/shm: Aucun fichier ou dossier de ce type drwxrwxrwt. 2 root root 300 nov 25 16:05 /dev/shm CHROOT: (sid-amd64-sbuild)root@soldur:/# ls -ld /dev/shm /run/shm lrwxrwxrwx. 1 root root8 Nov 23 2012 /dev/shm -> /run/shm drwxr-xr-x. 2 root root 4096 Nov 23 2012 /run/shm Creating /run/shm on the host is also fixing this. Is it possible that schroot is actually trying to resolve the /dev/shm -> /run/shm symlink outside of the chroot? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728096: schroot fails if shm tmpfs is mounted on /dev/shm
Hi, Just to be clear, I'm using the sbuild profile and the fstab for this profile contains the following line: tmpfs /dev/shmtmpfs defaults0 0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728096: schroot fails if shm tmpfs is mounted on /dev/shm
Package: schroot Version: 1.7.1-1 Severity: important Hi, schroot is failing with the following error when the shm tmpfs is mounted on /dev/shm on the host system: E: 10mount: E: Failed to resolve path “/var/lib/schroot/mount/sid-amd64-sbuild-blOhtk-17839/dev/shm”: Not a directory On the same machine remounting it to /run/shm and creating a symlink from /dev/shm fix the issues. I can reproduce this with both the version from unstable and experimental. See the attached log. Cheers Laurent Bigonville -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages schroot depends on: ii libboost-filesystem1.54.0 1.54.0-3 ii libboost-iostreams1.54.01.54.0-3 ii libboost-program-options1.54.0 1.54.0-3 ii libboost-regex1.54.01.54.0-3 ii libboost-system1.54.0 1.54.0-3 ii libc6 2.17-93 ii libgcc1 1:4.8.2-1 ii libpam0g1.1.3-10 ii libsbuild1.7.1 1.7.1-1 ii libstdc++6 4.8.2-1 ii schroot-common 1.7.1-1 schroot recommends no packages. Versions of packages schroot suggests: pn aufs-modules | unionfs-modules pn btrfs-tools ii debootstrap 1.0.55 ii lvm22.02.98-6+b1 ii qemu-user-static1.6.0+dfsg-2 -- no debconf information schroot.log.gz Description: application/gzip
