Comment 8 for bug 1789161

This is my proposed fix for this, which disallows you from doing a mount
--rbind of something that has MNT_LOCKED|MNT_UNBINDABLE set (I'm at a
conference so I've only compile-tested it so far -- I will try a test kernel in
a bit when my build finishes).

Obviously you're the expert here Eric, but I'm not sure that making
mount(MS_UNBINDABLE) fail is going to be less of a breakage than making rbind
fail if you are trying to rbind something that is *both* MNT_LOCKED and
MNT_UNBINDABLE. This also means that if the host does something like:

  % mount -t tmpfs tmpfs /proc/scsi
  % mount --make-unbindable /proc/scsi

Then this would be exploitable again (or if the set the entirety of /proc to be
runbindable, then a container could set /proc to private which would allow the
same exploit). Maybe this isn't a real issue though, I don't know.

From my reading of do_loopback, I got the (possibly mistaken) impression this
was an oversight of how copy_tree handles MNT_UNBINDABLE, and so it seems to me
that this is the natural place to fix it. But that's just my $0.02 and I'm sure
you definitely know more about this than me.