Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: David Howells <dhowells@redhat.com>,
	Jeff Layton <jlayton@redhat.com>,
	"Eric W. Biederman" <ebiederm@redhat.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: User-visible context-mount API
Date: Wed, 17 Jan 2018 04:17:27 +0000	[thread overview]
Message-ID: <20180117041727.GS13338@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAOssrKdn-ZhOB9V28uL-JK9zgNGJzF4cFBeyoqLLj4pADqNFVQ@mail.gmail.com>

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.

  reply	other threads:[~2018-01-17  4:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-15 16:07 David Howells
2018-01-15 17:31 ` Eric W. Biederman
2018-01-15 17:32 ` Eric W. Biederman
2018-01-16  9:01 ` Miklos Szeredi
2018-01-16 10:10 ` David Howells
2018-01-16 10:35   ` Miklos Szeredi
2018-01-16 14:18   ` David Howells
2018-01-17 10:43   ` Karel Zak
2018-01-16 14:55 ` David Howells
2018-01-16 15:40 ` David Howells
2018-01-16 16:41   ` Miklos Szeredi
2018-01-17  4:17     ` Al Viro [this message]
2018-01-17  9:53       ` Miklos Szeredi
2018-01-17 11:06         ` Karel Zak
2018-01-18  9:48           ` Miklos Szeredi
2018-01-19  2:27           ` Al Viro
2018-01-19  6:32         ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180117041727.GS13338@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --subject='Re: User-visible context-mount API' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).