Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932986AbcCIOtj (ORCPT ); Wed, 9 Mar 2016 09:49:39 -0500 Received: from mail-ob0-f175.google.com ([209.85.214.175]:36676 "EHLO mail-ob0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933042AbcCIOsY (ORCPT ); Wed, 9 Mar 2016 09:48:24 -0500 MIME-Version: 1.0 X-Originating-IP: [217.173.44.24] In-Reply-To: <20160309141840.GC23399@ubuntu-xps13> References: <1451930639-94331-1-git-send-email-seth.forshee@canonical.com> <1451930639-94331-17-git-send-email-seth.forshee@canonical.com> <20160309112923.GF8655@tucsk> <20160309141840.GC23399@ubuntu-xps13> Date: Wed, 9 Mar 2016 15:48:22 +0100 Message-ID: Subject: Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside of init_user_ns From: Miklos Szeredi To: Seth Forshee Cc: "Eric W. Biederman" , Alexander Viro , Serge Hallyn , Richard Weinberger , Austin S Hemmelgarn , Kernel Mailing List , linux-bcache@vger.kernel.org, dm-devel@redhat.com, linux-raid@vger.kernel.org, linux-mtd@lists.infradead.org, Linux-Fsdevel , fuse-devel , LSM , selinux@tycho.nsa.gov Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1463 Lines: 35 On Wed, Mar 9, 2016 at 3:18 PM, Seth Forshee wrote: > On Wed, Mar 09, 2016 at 12:29:23PM +0100, Miklos Szeredi wrote: >> On Mon, Jan 04, 2016 at 12:03:55PM -0600, Seth Forshee wrote: >> > -static int parse_fuse_opt(char *opt, struct fuse_mount_data *d, int is_bdev) >> > +static int parse_fuse_opt(char *opt, struct fuse_mount_data *d, int is_bdev, >> > + struct user_namespace *user_ns) >> > { >> > char *p; >> > memset(d, 0, sizeof(struct fuse_mount_data)); >> > d->max_read = ~0; >> > d->blksize = FUSE_DEFAULT_BLKSIZE; >> > + d->user_id = make_kuid(user_ns, 0); >> > + d->group_id = make_kgid(user_ns, 0); >> >> It is true that if "user_id=" or "group_id" options were omitted we used the >> zero uid/gid values. However, this isn't actually used by anybody AFAIK, and >> generalizing it for userns doesn't seem to make much sense. >> >> So I suggest we that we instead return an error if mounting from a userns AND >> neither "allow_other" nor both "user_id" and "group_id" are specified. > > But those are also used for ownership of the connection files in > fusectl. In an allow_other mount shouldn't those files by owned by > namespace root and not global root? Yes. Can't we use current_cred()->uid/gid? Or fsuid/fsgid maybe? When we have true unprivileged mounts, the user_id/group_id options become redundant anyway and we can just use the current credentials. Thanks, Miklos