[lxc-devel] [PATCH 1/1] pivot_root: switch to a new mechanism (v2)

[Andy Lutomirski]

On Mon, Sep 29, 2014 at 8:07 PM, Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> Quoting Andy Lutomirski (luto at amacapital.net):
>> On Mon, Sep 29, 2014 at 4:36 PM, Eric W. Biederman
>> <ebiederm at xmission.com> wrote:
>> > Andy Lutomirski <luto at amacapital.net> writes:
>> >
>> >> On Mon, Sep 29, 2014 at 4:22 PM, Eric W. Biederman
>> >> <ebiederm at xmission.com> wrote:
>> >>> Andy Lutomirski <luto at amacapital.net> writes:
>> >>>
>> >>>> To me, this smells like MNT_DETACH does something awful when there are
>> >>>> mounts under the detached mount.
>> >>>>
>> >>>> For example:
>> >>>>
>> >>>> mount --rbind / /mnt
>> >>>> umount -l /mnt
>> >>>>
>> >>>> does *not* end well on my system.  I find it hard to believe that this
>> >>>> behavior is intentional.
>> >>>
>> >>> Hmm.  I think what is happening on your system is in some way related to
>> >>> mount propgatation and systemd.   On my debian stable system system it
>> >>> works without problems.
>> >>
>> >> Try the variant with mount --make-rshared / first.  I reproduced it in
>> >> virtme, which doesn't use systemd -- it uses bash as its init daemon
>> >> :)
>> >
>> > Yes.  I so totally don't understand the motivation for the mount
>> > propgation semantics but it appears that is what you triggered.
>> >
>> > To test this I did:
>> >
>> > mount --make-rshared /
>> > mount --rbind / /mnt
>> > mount --make-rprivate /mnt
>> > umount -l /mnt
>> >
>> > And the unmounts did not propgate to /.
>>
>> I have no idea what's going on in that exploit you're looking at, but
>> I wonder whether this is the same effect.  I don't think that code is
>> unmounting "/", but I could have read it wrong.
>>
>> I would *love* to completely disallow mount propagation in recursive
>> bind mounts.  IMO they only make sense across namespaces.
>
> Perhaps the case where they are dangerous and should be turned into
> a MS_SLAVE is where dest is underneath src.  A simple case of
> mount --rbind /tree-a /tree-b very much may be intended to be
> truly shared.

I suppose (but I still don't see why).  Nonetheless, given that
MS_DETACH is the only control we have, the kernel is missing a way to
distinguish "undo the bind mount" from "blow away the tree entirely".

--Andy