Re: User-visible context-mount API

[Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>]

On Tue, Jan 16, 2018 at 05:41:46PM +0100, Miklos Szeredi wrote:

> Right.
> 
> Still, those two (propagation and flags) are properties of the mount.
> No fundamental difference in how to handle them, that I see.  Okay, we
> have MS_REC handling in the propagation and not in the flags, but
> that's something that might make sense for flags as well.
> 
> What's more interesting is how MS_PRIVATE + MS_REC semantics are
> complete failure in the real world: the logical thing would be to mark
> a mount private on the supplied mount AND propagate an umount event to
> everywhere else.

This is utter nonsense.  Most of the time it's "Fedora, in its infinite
bogo^Wwisdom has made everything shared; I don't fucking need that
idiocy, so please unshare this, this and that".  You really don't want
(or have permissions for) unmounting e.g. /mnt in namespace of init
when you do that.

Sure, we get tons of bug reports.  Due to idiotic Fedora setup, with
everything shared.  The same setup that would go up in flames on the
semantics change you propose.

If anything, "private bind on itself" would be a useful operation.
Turning given location into a mountpoint, and having everything
under it looking as it used to, but with no propagation at all.
Without bothering anybody else, even if location currently happens
to be on a shared/master mount.

I can slap that together for mount(2), but I'm not sure what a sane
combination of flags for that would look like ;-)  For fsmount
I think it would be very useful thing to have.