[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181013061141.GR32577@ZenIV.linux.org.uk>
Date: Sat, 13 Oct 2018 07:11:41 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Alan Jenkins <alan.christopher.jenkins@...il.com>
Cc: David Howells <dhowells@...hat.com>, linux-api@...r.kernel.org,
torvalds@...ux-foundation.org, ebiederm@...ssion.com,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
mszeredi@...hat.com
Subject: Re: [PATCH 31/34] vfs: syscall: Add fspick() to select a superblock
for reconfiguration [ver #12]
On Fri, Oct 12, 2018 at 03:49:50PM +0100, Alan Jenkins wrote:
> > +SYSCALL_DEFINE3(fspick, int, dfd, const char __user *, path, unsigned int, flags)
> > +{
> > + struct fs_context *fc;
> > + struct path target;
> > + unsigned int lookup_flags;
> > + int ret;
> > +
> > + if (!ns_capable(current->nsproxy->mnt_ns->user_ns, CAP_SYS_ADMIN))
> > + return -EPERM;
>
>
> This seems to accept basically any mount. Specifically: are you sure it's
> OK to return a handle to a SB_NO_USER superblock?
Umm... As long as we don't try to do pathname resolution from its ->s_root,
shouldn't be a problem and I don't see anything that would do that. I might've
missed something, but...
Powered by blists - more mailing lists