From mboxrd@z Thu Jan 1 00:00:00 1970 From: Seth Forshee Subject: Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside of init_user_ns Date: Wed, 9 Mar 2016 09:25:05 -0600 Message-ID: <20160309152505.GA28779@ubuntu-hedt> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fuse-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Miklos Szeredi Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Serge Hallyn , dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, LSM , Kernel Mailing List , linux-raid-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, fuse-devel , Austin S Hemmelgarn , linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, "Eric W. Biederman" , selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org, Linux-Fsdevel , Alexander Viro List-Id: linux-raid.ids On Wed, Mar 09, 2016 at 03:48:22PM +0100, Miklos Szeredi wrote: > 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? That would be a departure from the current behavior in the !allow_other case for unprivileged users. Since those mounts are done by an suid helper all of those ids would be root in the userns, wouldn't they? > When we have true unprivileged mounts, the user_id/group_id options > become redundant anyway and we can just use the current credentials. True, but we don't yet have that. Thanks, Seth ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 -- fuse-devel mailing list To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933032AbcCIPZT (ORCPT ); Wed, 9 Mar 2016 10:25:19 -0500 Received: from mail-ob0-f175.google.com ([209.85.214.175]:35688 "EHLO mail-ob0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932998AbcCIPZN (ORCPT ); Wed, 9 Mar 2016 10:25:13 -0500 Date: Wed, 9 Mar 2016 09:25:05 -0600 From: Seth Forshee To: Miklos Szeredi 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 Subject: Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside of init_user_ns Message-ID: <20160309152505.GA28779@ubuntu-hedt> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 09, 2016 at 03:48:22PM +0100, Miklos Szeredi wrote: > 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? That would be a departure from the current behavior in the !allow_other case for unprivileged users. Since those mounts are done by an suid helper all of those ids would be root in the userns, wouldn't they? > When we have true unprivileged mounts, the user_id/group_id options > become redundant anyway and we can just use the current credentials. True, but we don't yet have that. Thanks, Seth