From: Al Viro <viro@zeniv.linux.org.uk>
To: Sargun Dhillon <sargun@sargun.me>
Cc: Christoph Hellwig <hch@lst.de>,
linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
Kyle Anderson <kylea@netflix.com>,
Manas Alekar <malekar@netflix.com>
Subject: Re: [PATCH] fs: Validate flags and capabilities before looking up path in ksys_umount
Date: Mon, 4 Jan 2021 20:33:59 +0000 [thread overview]
Message-ID: <20210104203359.GO3579531@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20210104195127.GN3579531@ZenIV.linux.org.uk>
On Mon, Jan 04, 2021 at 07:51:27PM +0000, Al Viro wrote:
> On Wed, Dec 23, 2020 at 02:26:04AM -0800, Sargun Dhillon wrote:
> > ksys_umount was refactored to into split into another function
> > (path_umount) to enable sharing code. This changed the order that flags and
> > permissions are validated in, and made it so that user_path_at was called
> > before validating flags and capabilities.
> >
> > Unfortunately, libfuse2[1] and libmount[2] rely on the old flag validation
> > behaviour to determine whether or not the kernel supports UMOUNT_NOFOLLOW.
> > The other path that this validation is being checked on is
> > init_umount->path_umount->can_umount. That's all internal to the kernel.
> >
> > [1]: https://github.com/libfuse/libfuse/blob/9bfbeb576c5901b62a171d35510f0d1a922020b7/util/fusermount.c#L403
> > [2]: https://github.com/karelzak/util-linux/blob/7ed579523b556b1270f28dbdb7ee07dee310f157/libmount/src/context_umount.c#L813
>
> Sorry, I don't like that solution. If nothing else, it turns path_umount() into
> a landmine for the future. Yes, we have a regression, yes, we need to do something
> about it, but that's not a good way to do that.
>
> FWIW, I would rather separate the check of flags validity from can_umount()
> and lift _that_ into ksys_umount(), with "path_umount() relies upon the
> flags being minimally sane" comment slapped at path_umount() definition.
> The rest of can_umount() really shouldn't be taken out of there.
I mean something like the following; unlike your variant, may_mount() is left
where it is.
commit a0a6df9afcaf439a6b4c88a3b522e3d05fdef46f
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Mon Jan 4 15:25:34 2021 -0500
umount(2): move the flag validity checks first
Unfortunately, there's userland code that used to rely upon these
checks being done before anything else to check for UMOUNT_NOFOLLOW
support. That broke in 41525f56e256 ("fs: refactor ksys_umount").
Separate those from the rest of checks and move them to ksys_umount();
unlike everything else in there, this can be sanely done there.
Reported-by: Sargun Dhillon <sargun@sargun.me>
Fixes: 41525f56e256 ("fs: refactor ksys_umount")
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
diff --git a/fs/namespace.c b/fs/namespace.c
index d2db7dfe232b..9d33909d0f9e 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1713,8 +1713,6 @@ static int can_umount(const struct path *path, int flags)
{
struct mount *mnt = real_mount(path->mnt);
- if (flags & ~(MNT_FORCE | MNT_DETACH | MNT_EXPIRE | UMOUNT_NOFOLLOW))
- return -EINVAL;
if (!may_mount())
return -EPERM;
if (path->dentry != path->mnt->mnt_root)
@@ -1728,6 +1726,7 @@ static int can_umount(const struct path *path, int flags)
return 0;
}
+// caller is responsible for flags being sane
int path_umount(struct path *path, int flags)
{
struct mount *mnt = real_mount(path->mnt);
@@ -1749,6 +1748,10 @@ static int ksys_umount(char __user *name, int flags)
struct path path;
int ret;
+ // basic validity checks done first
+ if (flags & ~(MNT_FORCE | MNT_DETACH | MNT_EXPIRE | UMOUNT_NOFOLLOW))
+ return -EINVAL;
+
if (!(flags & UMOUNT_NOFOLLOW))
lookup_flags |= LOOKUP_FOLLOW;
ret = user_path_at(AT_FDCWD, name, lookup_flags, &path);
prev parent reply other threads:[~2021-01-04 21:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-23 10:26 [PATCH] fs: Validate flags and capabilities before looking up path in ksys_umount Sargun Dhillon
2021-01-04 19:51 ` Al Viro
2021-01-04 20:33 ` Al Viro [this message]
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=20210104203359.GO3579531@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=hch@lst.de \
--cc=kylea@netflix.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=malekar@netflix.com \
--cc=sargun@sargun.me \
/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.