Bug#762597: [buildd-tools-devel] Bug#762597: /var/lib/schroot/mounts should be in /var/run for --one-file-system

2014-11-24 Thread Roger Leigh
On Tue, Sep 23, 2014 at 03:55:40PM +0100, Ian Jackson wrote:
 If you have a directory schroot chroot whose source directory is the
 same as /, schroot's bind mount in /var/lib/schroot/mounts is
 invisible to file tree walking tools.
 
 That is, rsync --one-file-system (rsync -x), cp --one-file-system
 (cp -x), find -xdev, etc., do not notice the mount point, and
 typically traverse through it.
 
 This is far from ideal.  Now arguably this is a bug in bind mounts
 (perhaps a design bug).  But as it happens it is easy to work around
 this problem in schroot in a way that is both correct and will fix
 almost all the problems:
 
 Move /var/lib/schroot/mounts to /var/run/schroot/mounts or some such.
 
 Typically /var/run is a tmpfs.  As a result there will be a filesystem
 with a different devid between / and the chroot.  So to all the file
 tree walkers, it will look like two mount points.  Backup tools,
 find, etc., will not descend into schroot's bind mount because they'll
 stop at /var/run.

Hmm, this is an interesting problem.  Your proposed solution would
certainly provide a boundary to stop traversal, but I'm not sure it
would help in all situations, since e.g. for file-based chroots we
unpack them under /var/lib/schroot.  Putting the mounts themselves
under /var/run should be safe enough though.

In recent years, I've put the chroot directories in btrfs subvolumes,
where the subvolumes have a separate devid, and had that as a
separate filesytem (don't trust it enough for the rootfs).  Currently
implementing support for ZFS snapshots.

I'll need to do some testing of this to make sure it doesn't
break anything.  If you have any further thoughts or ideas, please
do let me know!


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#762597: [buildd-tools-devel] Bug#762597: /var/lib/schroot/mounts should be in /var/run for --one-file-system

2014-11-24 Thread Ian Jackson
Roger Leigh writes (Re: [buildd-tools-devel] Bug#762597: 
/var/lib/schroot/mounts should be in /var/run for --one-file-system):
 Hmm, this is an interesting problem.  Your proposed solution would
 certainly provide a boundary to stop traversal, but I'm not sure it
 would help in all situations, since e.g. for file-based chroots we
 unpack them under /var/lib/schroot.  Putting the mounts themselves
 under /var/run should be safe enough though.

Yes, you're right, I hadn't properly considered file-based chroots.  I
don't know how to fix those.  But as you say, my proposal at least
won't hurt them.

 In recent years, I've put the chroot directories in btrfs subvolumes,
 where the subvolumes have a separate devid, and had that as a
 separate filesytem (don't trust it enough for the rootfs).  Currently
 implementing support for ZFS snapshots.

Right.

 I'll need to do some testing of this to make sure it doesn't
 break anything.  If you have any further thoughts or ideas, please
 do let me know!

Thanks for your attention!

Regards,
Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org