[buildd-tools-devel] Bug#786566: schroot: Should mark bind mounts in the schroot as private
Raphael Hertzog
hertzog at debian.org
Wed Aug 12 19:08:33 UTC 2015
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/
More information about the Buildd-tools-devel
mailing list