linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Seth Forshee <seth.forshee@canonical.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Serge Hallyn <serge.hallyn@ubuntu.com>,
	fuse-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,
	Seth Forshee <seth.forshee@canonical.com>
Subject: [PATCH v2 0/3] fuse: Add support for mounts from pid/user namespaces
Date: Tue,  2 Sep 2014 10:44:53 -0500	[thread overview]
Message-ID: <1409672696-15847-1-git-send-email-seth.forshee@canonical.com> (raw)

Here's an updated set of patches for allowing fuse mounts from pid and
user namespaces. I discussed some of the issues we debated with the last
patch set (and a few others) with Eric at LinuxCon, and the updates here
mainly reflect the outcome of those discussions.

The stickiest issue in the v1 patches was the question of where to get
the user and pid namespaces from that are used for translating ids for
communication with userspace. Eric told me that for user namespaces at
least we need to grab a namespace at open or mount time and use only
that namespace to prevent certain types of attacks. That rules out the
suggestion of using the user ns of current in the read/write paths, and
I think it makes sense to handle pid and user namespaces similarly. So
in these patches I'm still grabbing the namespaces of current during
mount, but I've added an additional check to fail the mount if the
f_cred's userns for the fd to userspace doesn't match.

Another issue mentioned by Eric was what to use for i_[ug]id if the ids
from userspace don't map into the user namespace, which is going to be a
problem for any other filesystems which become mountable from user
namespaces as well. We discussed a few options for addressing this, the
most promising of which seems to be either using INVALID_[UG]ID for
these inodes or creating vfs-wide "nobody" ids for this purpose. After
thinking about it for a while I'm favoring using the invalid ids, but
I'm hoping to solicit some more feedback.

For now these patches are using invalid ids if the user doesn't map into
the namespace. I went through the vfs code and found one place where
this could be handled better (addressed in patch 1 of the series). The
only other issue I found was that currently no one, not even root, can
change onwership of such inodes, but I suspect we can find a way around
this.

The only other change since v1 is that I now fail changing file
ownership if the new uid or gid does not map into the namespace used for
userspace communication.

Thanks,
Seth


Seth Forshee (3):
  vfs: Check for invalid i_uid in may_follow_link()
  fuse: Translate pids passed to userspace into pid namespaces
  fuse: Add support for mounts from user namespaces

 fs/fuse/dev.c    | 13 +++++++------
 fs/fuse/dir.c    | 46 +++++++++++++++++++++++++++++++++-------------
 fs/fuse/fuse_i.h |  8 ++++++++
 fs/fuse/inode.c  | 31 +++++++++++++++++++++++--------
 fs/namei.c       |  2 +-
 5 files changed, 72 insertions(+), 28 deletions(-)


             reply	other threads:[~2014-09-02 15:45 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-02 15:44 Seth Forshee [this message]
2014-09-02 15:44 ` [PATCH v2 1/3] vfs: Check for invalid i_uid in may_follow_link() Seth Forshee
2014-09-05 17:05   ` Serge Hallyn
2014-09-05 19:00     ` Seth Forshee
2014-09-05 19:23       ` Serge Hallyn
2014-09-02 15:44 ` [PATCH v2 2/3] fuse: Translate pids passed to userspace into pid namespaces Seth Forshee
2014-09-05 17:10   ` Serge Hallyn
2014-09-02 15:44 ` [PATCH v2 3/3] fuse: Add support for mounts from user namespaces Seth Forshee
2014-09-05 16:48   ` Serge Hallyn
2014-09-05 17:36     ` Seth Forshee
2014-09-05 19:25       ` Serge Hallyn
2014-09-05 20:40 ` [PATCH v2 0/3] fuse: Add support for mounts from pid/user namespaces Seth Forshee
2014-09-10 12:35 ` Seth Forshee
2014-09-10 16:21   ` Serge E. Hallyn
2014-09-10 16:42     ` Seth Forshee
2014-09-11 18:10       ` Seth Forshee
2014-09-23 22:29         ` Eric W. Biederman
2014-09-24 13:29           ` Seth Forshee
2014-09-24 17:10             ` Eric W. Biederman
2014-09-25 15:04               ` Miklos Szeredi
2014-09-25 16:21                 ` Seth Forshee
2014-09-25 18:05                 ` Eric W. Biederman
2014-09-25 18:44                   ` Seth Forshee
2014-09-25 18:53                     ` Seth Forshee
2014-09-25 19:14                     ` Eric W. Biederman
2014-09-25 19:48                       ` Seth Forshee
2014-09-27  1:41                         ` Eric W. Biederman
2014-09-27  4:24                           ` Seth Forshee
2014-09-29 19:34                             ` Eric W. Biederman
2014-09-30 16:25                               ` Seth Forshee
2014-10-05 16:48                                 ` Seth Forshee
2014-10-06 16:00                                   ` Serge Hallyn
2014-10-06 16:31                                     ` Seth Forshee
2014-10-06 16:36                                       ` Serge Hallyn
2014-09-23 16:07 ` Miklos Szeredi
2014-09-23 16:26   ` Seth Forshee
2014-09-23 17:03     ` Miklos Szeredi
2014-09-23 17:33       ` Seth Forshee
2014-09-23 21:46       ` Eric W. Biederman

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=1409672696-15847-1-git-send-email-seth.forshee@canonical.com \
    --to=seth.forshee@canonical.com \
    --cc=ebiederm@xmission.com \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=serge.hallyn@ubuntu.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 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).