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

[Raphael Hertzog]

Hi,

On Fri, 22 May 2015, Tyler Hicks wrote:
> That has worked pretty well for many filesystems that would be mounted
> at /home/$USER. However, I've recently had a lot of eCryptfs users
> reporting issues when using systemd as their init system since systemd
> uses shared mount propagation for mounts.

Can you point me to some systemd documentation proving your assertion?

I was not able to find the relevant documentation but you appear to be
right. On a wheezy system "/" is not marked as shared while on jessie
it is (you can see that in "cat /proc/self/mountinfo" in the 7th field
with the presence/absence of "shared:X").

Relevant documentation:
$ man proc
https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt

But I don't understand why /home would also inherits from the shared
attribute by default... that said this appears to be the case for me here
too (not with /home in my specific case but another mount point).

> /home/$USER is unmounted in the host environment when schroot sessions
> are ended due to the unmount events being propagated outside of the
> schroot session's subdirectory.
> 
> I believe that the best fix is to mark bind mount points, under the
> schroot session's subdirectory, as private. Also, rbind mount points
> will need to be marked as rprivate.

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?

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").

Cheers,

PS: Roger, Tyler forgot to CC you in his last reply, you might want to
check the bug report history.
-- 
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/