[lxc-devel] [PATCH 3/3] fuse: Allow mounts from user namespaces

[Eric W. Biederman]

Seth Forshee <seth.forshee at canonical.com> writes:

> On Mon, Jul 21, 2014 at 03:09:14PM +0200, Miklos Szeredi wrote:
>> On Mon, Jul 21, 2014 at 2:47 PM, Seth Forshee
>> <seth.forshee at 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 at 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().
>
> Okay, that seems like it should work.
>
>> > 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)?
>
> Nothing, but I'm having a hard time imagining why that would ever be
> useful. The user/group ids passed in the mount options would have to be
> mapped into that namespace, otherwise all requests will just fail in the
> check you suggest above. The only thing I can think of would be if
> someone wanted to proxy mounts trough a process in a more privileged
> context, but then the main point of these patches is to make that
> unnecessary.
>
> But I also think your approach should work just as well as mine for the
> use cases that do make sense to me, so I'll go ahead and give it a
> try.

A few observations that I don't think I have seen come up in this
thread.

In my earlier experiments with mounting filesystems in other user
namespaces it did wind up making sense to have a notion of this is
the user namespace that things are represented in on disk, and
that wound up covering odd corner cases like acls.  For fuse
I don't recall if any of those corner cases exists.

At the same time my conversion experience also showed that performing
the conversion to/from kuid and kgids as close to the user space
interface as close as possible was the lease error prone and most
secure way of handling things.

For the file descriptors used for talking to a fuse server I would be
inclined to capture a user and pid namespace at open time to use for
your conversions.   This avoids using current and getting into the
problem of file descriptors that change behavior when passed from
process to process.

I definitely agree that using kuids kgids, and struct pid through the
fuse filesystem internally is the least error prone way to go.

Eric