All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: Miklos Szeredi <miklos@szeredi.hu>,
	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 15:09:14 +0200	[thread overview]
Message-ID: <CAJfpegs=V5BpNdgn1JSLsvUsAnmhPvGJZobF1y_NAysb==Z1-A@mail.gmail.com> (raw)
In-Reply-To: <20140721124725.GB111224@ubuntu-hedt>

On Mon, Jul 21, 2014 at 2:47 PM, Seth Forshee
<seth.forshee@canonical.com> wrote:
> 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.

You can add that check in fuse_dev_do_read() as well.  If the
fsuid/fsgid doesn't exist in the "server's" namespace, then set
req->out.h.error and call request_end().

> Can you elaborate on what special situations might violate these
> assumptions or otherwise cause problems?

What's preventing a fuse fs implementation from handling FUSE_INIT in
one process and then handling the rest in a different process
(possibly in a different namespace)?

Thanks,
Miklos

  reply	other threads:[~2014-07-21 13:09 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
2014-07-21 13:09       ` Miklos Szeredi [this message]
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='CAJfpegs=V5BpNdgn1JSLsvUsAnmhPvGJZobF1y_NAysb==Z1-A@mail.gmail.com' \
    --to=miklos@szeredi.hu \
    --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=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.