All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Howells <dhowells@redhat.com>
Cc: mszeredi@redhat.com, viro@ZenIV.linux.org.uk, jlayton@redhat.com,
	ebiederm@redhat.com, linux-fsdevel@vger.kernel.org
Subject: Re: User-visible context-mount API
Date: Mon, 15 Jan 2018 11:32:29 -0600	[thread overview]
Message-ID: <87y3kzni36.fsf@xmission.com> (raw)
In-Reply-To: <28167.1516032442@warthog.procyon.org.uk> (David Howells's message of "Mon, 15 Jan 2018 16:07:22 +0000")

David Howells <dhowells@redhat.com> writes:

> I've been looking at the context-mount API visible to userspace as I need to
> adjust the security ops to handle it.  I'm thinking I probably need something
> like the following system calls.  Note that:

Is there supposed to be a question in this?
Are you asking for review of your basic design?

Eric

>  topology_flags are MS_PRIVATE, MS_SLAVE, MS_SHARED, MS_UNBINDABLE.
>
>  mount_flags are things like MS_NOSUID, MS_NODEV, MS_NOEXEC that get
>  translated to MNT_* flags in the kernel.
>
>  (1) Open a filesystem and create a blank context from it:
>
> 	fd = fsopen(const char *fs_name, unsigned int flags, ...);
>
>      where flags includes FSOPEN_CLOEXEC, FSOPEN_CREATE_ONLY (don't reuse
>      superblock).
>
>  (2) Access and change the context:
>
> 	write(fd, "<command>", ...);
> 	read(fd, ...);
> 	ioctl(fd, ...);
>
>  (3) Create and set up a context for an existing mountpoint:
>
> 	fd = fspick(int dfd, const char *path, unsigned int flags);
>
>      where flags includes FSPICK_CLOEXEC.
>
>  (4) Create a mountpoint on a path, using a context to supply the superblock
>      details:
>
> 	mount_create(int fd, int dfd, const char *path,
> 		     unsigned int topology_flags,
> 		     unsigned int mount_flags);
>
>  (5) Move a mount:
>
> 	mount_move(int from_dfd, const char *frompath,
> 		   int to_dfd, const char *topath);
>
>      This might want to take new topology flags algo.
>
>  (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);
>
>  (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().
>
> Note that two things are missing from the list:
>
>  (1) Bind mount.  This is done by:
>
> 	fd = fspick("/mnt/a");
> 	mount_create(fd, ..., "/mnt/b", ...);
> 	mount_create(fd, ..., "/mnt/c", ...);
> 	mount_create(fd, ..., "/mnt/d", ...);
>
>  (2) Remount.  Superblock reconfiguration is done by something like:
>
> 	fd = fspick("/mnt/a");
> 	write(fd, "? fs");
> 	read(fd, filesystem_type);
> 	write(fd, "o user_xattr"); // Indicate changes to be made
> 	write(fd, "x reconfigure"); // Perform the reconfiguration
>
> Thinking further on this, maybe I should make a mountpoint-context also, so
> that it can be loaded up with target namespace information and other goodies.
> This would vastly expand the parameter space for a mountpoint beyond the few
> syscall args available.  Creating a new mount might then look like:
>
> 	sbfd = fsopen("ext4");
> 	write(sbfd, "d /dev/sda1");
> 	write(sbfd, "o user_xattr");
> 	write(sbfd, "x commit");
>
> 	mfd = mount_new();
> 	write(mfd, "ns mnt 123"); // where fd 123 refers to a mount namesapce
> 	write(mfd, "o bind=1"); // Set MS_BIND
> 	write(mfd, "o nosuid=1"); // Set MS_NOSUID
>
> 	mount_create(mfd, AT_FDCWD, "/mnt/a", sbfd);
>
> David

  parent reply	other threads:[~2018-01-15 17:33 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-15 16:07 User-visible context-mount API David Howells
2018-01-15 17:31 ` Eric W. Biederman
2018-01-15 17:32 ` Eric W. Biederman [this message]
2018-01-16 14:55   ` David Howells
     [not found] ` <28167.1516032442-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2018-01-16  9:01   ` Miklos Szeredi
2018-01-16  9:01     ` Miklos Szeredi
2018-01-16 10:10     ` David Howells
2018-01-16 10:35       ` Miklos Szeredi
     [not found]       ` <CAOssrKc46bf=yme=zSubYF6t-TGfxEpCaKMQ6GVp30-vuaXWLw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-16 14:18         ` David Howells
2018-01-16 14:18           ` David Howells
     [not found]       ` <22576.1516097412-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2018-01-17 10:43         ` Karel Zak
2018-01-17 10:43           ` Karel Zak
     [not found] ` <CAOssrKdgudK7kKbhQBAnV9EwzHBq=4+9M26JGfmhNDGrGXmnFg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-16 15:40   ` David Howells
2018-01-16 15:40     ` David Howells
     [not found]     ` <1643.1516117204-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2018-01-16 16:41       ` Miklos Szeredi
2018-01-16 16:41         ` Miklos Szeredi
     [not found]         ` <CAOssrKdn-ZhOB9V28uL-JK9zgNGJzF4cFBeyoqLLj4pADqNFVQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-17  4:17           ` Al Viro
2018-01-17  4:17             ` Al Viro
2018-01-17  9:53             ` Miklos Szeredi
     [not found]               ` <CAOssrKfN_ZT5yJC1mxkhUf6FG=_eMD4nzQtETfu_4X3vOf1kHw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-17 11:06                 ` Karel Zak
2018-01-17 11:06                   ` Karel Zak
     [not found]                   ` <20180117110633.zneqvnjzgxkv4yc2-xkT7n84Rsxv/9pzu0YdTqQ@public.gmane.org>
2018-01-18  9:48                     ` Miklos Szeredi
2018-01-18  9:48                       ` Miklos Szeredi
2018-01-19  2:27                     ` Al Viro
2018-01-19  2:27                       ` Al Viro
2018-01-19  6:32                 ` 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=87y3kzni36.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=viro@ZenIV.linux.org.uk \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.