All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jann Horn <jannh@google.com>
To: David Howells <dhowells@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	Linux API <linux-api@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-security-module <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH 02/10] vfs: syscall: Add move_mount(2) to move mounts around
Date: Wed, 20 Feb 2019 17:23:46 +0100	[thread overview]
Message-ID: <CAG48ez0fvv4CT5S7xgW92Ouad8N-r9RY89QbUwRVYd9DLKePiw@mail.gmail.com> (raw)
In-Reply-To: <155059611887.17079.12991580316407924257.stgit@warthog.procyon.org.uk>

On Tue, Feb 19, 2019 at 6:08 PM David Howells <dhowells@redhat.com> wrote:
> Add a move_mount() system call that will move a mount from one place to
> another and, in the next commit, allow to attach an unattached mount tree.
>
> The new system call looks like the following:
>
>         int move_mount(int from_dfd, const char *from_path,
>                        int to_dfd, const char *to_path,
>                        unsigned int flags);
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: linux-api@vger.kernel.org
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
[...]
> +/*
> + * Move a mount from one place to another.
> + *
> + * Note the flags value is a combination of MOVE_MOUNT_* flags.
> + */
> +SYSCALL_DEFINE5(move_mount,
> +               int, from_dfd, const char *, from_pathname,
> +               int, to_dfd, const char *, to_pathname,
> +               unsigned int, flags)
> +{
> +       struct path from_path, to_path;
> +       unsigned int lflags;
> +       int ret = 0;
> +
> +       if (!may_mount())
> +               return -EPERM;
> +
> +       if (flags & ~MOVE_MOUNT__MASK)
> +               return -EINVAL;
> +
> +       /* If someone gives a pathname, they aren't permitted to move
> +        * from an fd that requires unmount as we can't get at the flag
> +        * to clear it afterwards.
> +        */
> +       lflags = 0;
> +       if (flags & MOVE_MOUNT_F_SYMLINKS)      lflags |= LOOKUP_FOLLOW;
> +       if (flags & MOVE_MOUNT_F_AUTOMOUNTS)    lflags |= LOOKUP_AUTOMOUNT;
> +       if (flags & MOVE_MOUNT_F_EMPTY_PATH)    lflags |= LOOKUP_EMPTY;
> +
> +       ret = user_path_at(from_dfd, from_pathname, lflags, &from_path);
> +       if (ret < 0)
> +               return ret;
> +
> +       lflags = 0;
> +       if (flags & MOVE_MOUNT_T_SYMLINKS)      lflags |= LOOKUP_FOLLOW;
> +       if (flags & MOVE_MOUNT_T_AUTOMOUNTS)    lflags |= LOOKUP_AUTOMOUNT;
> +       if (flags & MOVE_MOUNT_T_EMPTY_PATH)    lflags |= LOOKUP_EMPTY;
> +
> +       ret = user_path_at(to_dfd, to_pathname, lflags, &to_path);
> +       if (ret < 0)
> +               goto out_from;
> +
> +       ret = security_move_mount(&from_path, &to_path);
> +       if (ret < 0)
> +               goto out_to;

Wouldn't you want to call this from do_move_mount() instead for
consistency? If MS_MOVE and this thing perform the same logical
operation, they should probably also call the same LSM hook.

> +       ret = do_move_mount(&from_path, &to_path);
> +
> +out_to:
> +       path_put(&to_path);
> +out_from:
> +       path_put(&from_path);
> +       return ret;
> +}
[...]
> diff --git a/include/uapi/linux/mount.h b/include/uapi/linux/mount.h
> index fd7ae2e7eccf..3634e065836c 100644
> --- a/include/uapi/linux/mount.h
> +++ b/include/uapi/linux/mount.h
> @@ -61,4 +61,15 @@
>  #define OPEN_TREE_CLONE                1               /* Clone the target tree and attach the clone */
>  #define OPEN_TREE_CLOEXEC      O_CLOEXEC       /* Close the file on execve() */
>
> +/*
> + * move_mount() flags.
> + */
> +#define MOVE_MOUNT_F_SYMLINKS          0x00000001 /* Follow symlinks on from path */

"Follow symlinks" sounds a bit misleading. LOOKUP_NOFOLLOW only
applies to the last element of the path; and there is a pending
patchset that's going to let userspace ask the kernel to actually not
follow *any* symlinks on the path with O_NOSYMLINKS, so this might
confuse people. Maybe change the comment to "don't follow trailing
symlink", or something like that?

  parent reply	other threads:[~2019-02-20 16:24 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-19 17:08 [PATCH 00/10] VFS: Provide new mount UAPI David Howells
2019-02-19 17:08 ` [PATCH 01/10] vfs: syscall: Add open_tree(2) to reference or clone a mount David Howells
2019-02-19 17:08 ` [PATCH 02/10] vfs: syscall: Add move_mount(2) to move mounts around David Howells
2019-02-20 12:32   ` Alan Jenkins
2019-02-20 12:41     ` Alan Jenkins
2019-02-20 16:23   ` Jann Horn [this message]
2019-07-08 12:02   ` Tetsuo Handa
2019-07-08 13:18     ` Al Viro
2019-07-08 17:12       ` Eric W. Biederman
2019-07-08 18:01         ` Al Viro
2019-07-08 18:13           ` Al Viro
2019-07-08 20:21           ` Al Viro
2019-07-09  0:13             ` Eric W. Biederman
2019-07-09 10:51               ` Tetsuo Handa
2019-07-22 10:12                 ` Tetsuo Handa
2019-07-23  4:16                   ` John Johansen
2019-07-23 13:45                     ` Tetsuo Handa
2019-08-06 10:43                       ` Tetsuo Handa
2019-08-09 15:44                         ` [PATCH] LSM: Disable move_mount() syscall when TOMOYO or AppArmor is enabled Tetsuo Handa
2019-08-22  3:51                         ` [RFC][PATCH] fix d_absolute_path() interplay with fsmount() Al Viro
2019-08-30 10:11                           ` Tetsuo Handa
2019-07-23 21:45             ` [PATCH 02/10] vfs: syscall: Add move_mount(2) to move mounts around James Morris
2019-07-23 23:30               ` Al Viro
2019-02-19 17:08 ` [PATCH 03/10] teach move_mount(2) to work with OPEN_TREE_CLONE David Howells
2019-02-20 18:59   ` Alan Jenkins
2019-02-26 17:45   ` Alan Jenkins
2019-02-19 17:08 ` [PATCH 04/10] Make anon_inodes unconditional David Howells
2019-02-19 17:09 ` [PATCH 05/10] vfs: syscall: Add fsopen() to prepare for superblock creation David Howells
2019-02-19 17:09 ` [PATCH 06/10] vfs: Implement logging through fs_context David Howells
2019-02-19 17:09 ` [PATCH 07/10] vfs: syscall: Add fsconfig() for configuring and managing a context David Howells
2019-02-19 17:09 ` [PATCH 08/10] vfs: syscall: Add fsmount() to create a mount for a superblock David Howells
2019-02-19 17:09 ` [PATCH 09/10] vfs: syscall: Add fspick() to select a superblock for reconfiguration David Howells
2019-02-19 17:09 ` [PATCH 10/10] vfs: Add a sample program for the new mount API David Howells

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=CAG48ez0fvv4CT5S7xgW92Ouad8N-r9RY89QbUwRVYd9DLKePiw@mail.gmail.com \
    --to=jannh@google.com \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --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.