All of lore.kernel.org
 help / color / mirror / Atom feed
From: Seth Forshee <seth.forshee@canonical.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>,
	fuse-devel <fuse-devel@lists.sourceforge.net>,
	lxc-devel@lists.linuxcontainers.org,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Serge Hallyn <serge.hallyn@ubuntu.com>,
	"Michael H. Warfield" <mhw@wittsend.com>
Subject: Re: [PATCH 3/3] fuse: Allow mounts from user namespaces
Date: Mon, 21 Jul 2014 07:47:25 -0500	[thread overview]
Message-ID: <20140721124725.GB111224@ubuntu-hedt> (raw)
In-Reply-To: <CAJfpegvMeiZG09U3aXvxKV+GPSn6zFgLbUwXGpTuoVSbnvgfmw@mail.gmail.com>

On Fri, Jul 18, 2014 at 05:33:23PM +0200, Miklos Szeredi wrote:
> On Mon, Jul 14, 2014 at 9:18 PM, Seth Forshee
> <seth.forshee@canonical.com> wrote:
> > Update fuse to allow mounts from user namespaces. During mount
> > current_user_ns() is stashed away,
> 
> Same thing here.  While practically this may work, it's theoretically
> wrong, and possibly may go wrong in special situations.   In fuse
> there's no official "server process", so storing information, like
> namespace, about one is going to be wrong.

What you're suggesting would probably work fine when dealing with pids.
It's not going to work though for the checks I've added in
fuse_allow_current_process() that the process is in the mount owner's
user ns, and without those checks or something similar I don't think
it's safe to permit allow_other for user ns mounts.

I realize that "server process" isn't perfect terminology, it was just
the shorthand I came up with for "the process reading/writing on
/dev/fuse for this super block," which I assumed would be a single
process and certainly not multiple processes in different namespaces.
Can you elaborate on what special situations might violate these
assumptions or otherwise cause problems?

Maybe an alternative approach for the user namspace would be to use the
one which owns the mount namespace of the mount. I'm just not sure off
the top of my head whether or not there's a way for fuse to get to that
information.


  reply	other threads:[~2014-07-21 12:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-14 19:18 [PATCH 0/3] fuse: Allow mounts in containers Seth Forshee
2014-07-14 19:18 ` [PATCH 1/3] fuse/dev: Fix unbalanced calls to kunmap_atomic() during splice I/O Seth Forshee
2014-07-18 15:21   ` Miklos Szeredi
2014-07-21 12:18     ` Seth Forshee
2014-07-14 19:18 ` [PATCH 2/3] fuse: Translate pid making a request into the server's pid namespace Seth Forshee
2014-07-18 15:29   ` Miklos Szeredi
2014-07-14 19:18 ` [PATCH 3/3] fuse: Allow mounts from user namespaces Seth Forshee
2014-07-18 15:33   ` Miklos Szeredi
2014-07-21 12:47     ` Seth Forshee [this message]
2014-07-21 13:09       ` Miklos Szeredi
2014-07-21 14:34         ` Seth Forshee
2014-07-21 18:02           ` Eric W. Biederman
2014-07-22  3:30             ` Seth Forshee
2014-07-25 19:46               ` Seth Forshee
2014-07-26 16:27                 ` Miklos Szeredi
2014-08-15 13:15                   ` Seth Forshee

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=20140721124725.GB111224@ubuntu-hedt \
    --to=seth.forshee@canonical.com \
    --cc=ebiederm@xmission.com \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lxc-devel@lists.linuxcontainers.org \
    --cc=mhw@wittsend.com \
    --cc=miklos@szeredi.hu \
    --cc=serge.hallyn@ubuntu.com \
    /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.