Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: dhowells@redhat.com, viro <viro@zeniv.linux.org.uk>,
	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: Tue, 16 Jan 2018 10:10:12 +0000	[thread overview]
Message-ID: <22576.1516097412@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAOssrKdgudK7kKbhQBAnV9EwzHBq=4+9M26JGfmhNDGrGXmnFg@mail.gmail.com>

Miklos Szeredi <mszeredi@redhat.com> wrote:

> >  (6) Adjust a mountpoint's topology flags:
> >
> >         mount_set_topology(int dfd, const char *path,
> >                            unsigned int topology_flags);
> >
> >  (7) Reconfigure a mountpoint:
> >
> >         mount_reconfigure(int dfd, const char *path,
> >                           unsigned int mount_flags);
> 
> 
> What's the fundamental  difference between topology flags and other
> flags?  Why two syscalls?

Inside the kernel the MS_* flags appear to belong to a number of fundamentally
different classes:

 (1) Things like MS_SILENT and MS_REMOUNT which affect the behaviour of the
     mount process, but aren't persistent beyond that.

 (2) Inter-namespace topology management, controlling how mounts are shared
     and duplicated between namespaces.

 (3) Restrictions on accesses through a particular mountpoint, eg. MS_NODEV,
     MS_NOEXEC.

 (4) Instructions to a filesystem on how a superblock is to behave.

I think the classes are fundamentally different - and we've already separated
(4) from the others inside the kernel.  However, I've no great objection to
keeping (2) and (3) together in the same mask.  It just sounds cleaner to
separate them.  Do we foresee adding any extra flags to these classes?

> Also I think we need a "mask" argument telling the kernel which flags
> need to be changed.

Sounds reasonable.

> >  (8) Change R/O protection on a mountpoint:
> >
> >         mount_protect(int dfd, const char *path,
> >                       bool read_only);
> >
> >      This involves changing the R/O protection on the superblock also, but
> >      might be mergeable with mount_reconfigure().
> 
> Methinks this should be merged with mount_reconfigure(), and if
> superblock state needs to be changed, than that should be done with
> the "remount" procedure below.

Maybe - the problem is that it's harder to manage if you've got multiple
mounts attached to a single superblock as you can only change the superblock
state if all the mounts are R/O.

> >         write(mfd, "o bind=1"); // Set MS_BIND
> 
> What does MS_BIND mean here?

Sorry, bad example; MS_BIND wouldn't be allowed there.  Consider the following
instead:

     write(mfd, "o nodev=1"); // Set 'MS_NODEV'

> >         write(mfd, "o nosuid=1"); // Set MS_NOSUID
> >
> >         mount_create(mfd, AT_FDCWD, "/mnt/a", sbfd);
> 
> Yeah, more flexible, but also more complicated, with mount_create()
> now taking 3 file descriptors, ugh...

Yeah, I know:-/ ... but there are more parameters that I can foresee adding
(such as [ug]id mapping tables), and a syscall just doesn't have enough
argument space.  Also, I think that we need to set all the parameters on a
mountpoint at the time of creation and that doing this retroactively isn't a
good idea, since it's live as soon as it's created.

David

  parent reply	other threads:[~2018-01-16 10:10 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 [this message]
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
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=22576.1516097412@warthog.procyon.org.uk \
    --to=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 \
    --cc=viro@zeniv.linux.org.uk \
    --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).