[buildd-tools-devel] Bug#786566: schroot: Should mark bind mounts in the schroot as private

[Raphael Hertzog]

On Tue, 11 Aug 2015, Tyler Hicks wrote:
> http://www.freedesktop.org/software/systemd/man/systemd.exec.html
> 
> Search for 'Defaults to shared'.

Ok. It's not clear to me that this is related... this is about having
a shared filesystem namespace in which the mount command is called.

How does it translate to the fact that the actual mount point is
tagged as shared? I checked

> All mounts of my /etc/fstab file are being configured with shared
> propagation, not just '/'.

Yeah, me too. But I don't find this documented anywhere.

> > Would it not be better to mark them as "slave" instead? That way
> > propagation from the host to the chroot works but not the other
> > way around?
> 
> That's a possibility that I considered but I thought it would be best to
> simply restore the kernel's default mount propagation mode (private) to
> keep from surprising users.

Actually the root of the chroot is already marked as private, cf do_mount()
in /etc/schroot/setup.d/10mount

    # Mark this mountpoint as private; some systems have / as a shared mountpoint.
    # As an example, assume /home/m/ch is the chroot directory.
    # schroot will mount -o bind /home/m/ch to /var/lib/schroot/mount/ch-123
    # Afterwards, it will bind-mount /dev to /var/lib/schroot/mount/ch-123.
    # With shared mountpoints, that mount will also show up in the original
    # /home/m/ch. This is a problem once schroot mounted /home: the following
    # mount of /tmp will show up in /var/lib/schroot/mount/ch-123/tmp,
    # /home/m/ch/tmp and /home/m/ch/home/m/ch/tmp (!), which leads to failure
    # on unmounting.
    if [ "$(uname -s)" = "Linux" ]; then
      mount --make-private "$3"
    fi

> > Also recent mount allow you to specify mount options like "shared",
> > "slave", "private" so we should respect this choice when
> > the user has supplied them in the fstab... (or "rshared", "rprivate",
> > "rslave").
> 
> I made sure to preserve that functionality. Only the bind and rbind
> mounts in the profile's fstab are being set to private. The mount
> utility does not support having bind/rbind and a mount propagation mode
> on the same line. If a user wants to set a custom mount propagation
> mode, they'd have to do so with a new line in fstab. That's the case
> with the mount utility and with my proposed patch to schroot.

That's no longer the case. As I said, mount now accepts such options
(even for bind mount), cf man mount:

  Since util-linux 2.23 the  mount  command  allows  to  use  several
  propagation  flags together  and also together with other mount
  operations.  This feature is EXPERIMENTAL.  The propagation flags are
  applied by additional mount(2) syscalls  when  the  preceding mount
  operations were successful.  Note that this use case is not atomic.  It
  is possible to specify the propagation flags in fstab(5)  as  mount
  options  (private,  slave, shared, unbindable, rprivate, rslave,
  rshared, runbindable).

I just tested this by changing one /etc/schroot/*/fstab to add a "slave"
option on a bind mount and it worked as expected.

Thus I believe that you should not call mount --make-private if one of
those option is set in the fstab file.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/