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

[Tyler Hicks]

On 2015-08-11 22:51:33, Raphael Hertzog wrote:
> 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?

http://www.freedesktop.org/software/systemd/man/systemd.exec.html

Search for 'Defaults to shared'.

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

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

> 
> > /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?

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.

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

> 
> Cheers,
> 
> PS: Roger, Tyler forgot to CC you in his last reply, you might want to
> check the bug report history.

Thanks!

Tyler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20150811/434b0def/attachment.sig>