Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1364833

Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside of init_user_ns

Path csiph.com!aioe.org!bofh.it!news.nic.it!robomod
From Seth Forshee <seth.forshee@canonical.com>
Newsgroups linux.kernel
Subject Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside of init_user_ns
Date Fri, 25 Mar 2016 21:40:02 +0100
Message-ID <rgGGu-7eY-3@gated-at.bofh.it> (permalink)
References <qNhJT-6ZN-3@gated-at.bofh.it> <qNhJV-6ZN-43@gated-at.bofh.it> <raKts-7bN-1@gated-at.bofh.it> <raN7X-yK-1@gated-at.bofh.it> <raNB1-L2-27@gated-at.bofh.it> <raOdI-1eq-7@gated-at.bofh.it> <raOGK-1uZ-7@gated-at.bofh.it> <raPMu-2zP-21@gated-at.bofh.it> <rcHKO-sV-7@gated-at.bofh.it>
X-Original-To Miklos Szeredi <miklos@szeredi.hu>
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=wkkfp2hm+5X79mHSNaWKngCSSRbsQChFoLiORpCQJ2E=; b=DSnEyw9WzeOOtliKCLBudB3Olf3b2NhAokcV72aK0+lYkZUBFwYGH/RYGrSED76Yyx m2d7mnXcn0n6EYdvPIQ/wpIL8jTVMql1hLh+isVVdM302LBtJ7zihoaz2LdgYjhtSmPd 0Jpg1bdUUJDo75iQS31WB3RMvloOxoVcgyEgqNt/2JD9odmmmMvNTFUZNGllA6GcK2wd UcFVfu5dHcEK50yoBO0HmJngz88VwewBrINVLiYRk9iKLAcr2rkik6kkS0d5DEOar/ee MaMNAWGzeKg8XEMZSYG6fc7NsIP85EAvG202pwex7a75fed12JIMCqLBsWSZug0Gx9Rl eCnA==
X-Google-Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=wkkfp2hm+5X79mHSNaWKngCSSRbsQChFoLiORpCQJ2E=; b=E7gVK5yQ1Hy/tI4kw16e/xABFauZ4ug0aYFfBgJMukBVuUYfD52SNbLqHmExncj7r/ 4NzT3rGP5PNb8ZAQXLhYJMJN4f3C8L2zuHvfKEKvXlId9AiqeEwoOjukMpOOJRUQ/nnu 8dZi9waZykBz7y+3sa9U0PXwCTMqrIARpKa2w4UC1L/eyng837r1EoNPNwtIh0kNLK4V DW70EmWuZf+/ADPH5Bou+nqNoaqLWAUwrgEUeL1sqFzA6B5P4vu5jS9oWzWYSt9IBZW+ aLVkVQ58UDCStafQXH3kyDeJwFf2jQ2ZSqtigwF5bL7cX0POySYZUt45iAPYYamX1qzQ cTGA==
X-Gm-Message-State AD7BkJIafJlZ4imD29U4KGUqFS9Uo4TgqbNbyh9mLx/JXjelAT1jkQfxUdkwyUj7jAO22Qzt
X-Received by 10.157.10.197 with SMTP id 63mr7015739otq.155.1458937909690; Fri, 25 Mar 2016 13:31:49 -0700 (PDT)
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.5.24 (2015-08-30)
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 57
Organization linux.* mail to news gateway
X-Original-Cc "Eric W. Biederman" <ebiederm@xmission.com>, Alexander Viro <viro@zeniv.linux.org.uk>, Serge Hallyn <serge.hallyn@canonical.com>, Richard Weinberger <richard.weinberger@gmail.com>, Austin S Hemmelgarn <ahferroin7@gmail.com>, Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-bcache@vger.kernel.org, dm-devel@redhat.com, linux-raid@vger.kernel.org, linux-mtd@lists.infradead.org, Linux-Fsdevel <linux-fsdevel@vger.kernel.org>, fuse-devel <fuse-devel@lists.sourceforge.net>, LSM <linux-security-module@vger.kernel.org>, selinux@tycho.nsa.gov
X-Original-Date Fri, 25 Mar 2016 15:31:48 -0500
X-Original-Message-ID <20160325203148.GA4055@ubuntu-xps13>
X-Original-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> <CAJfpegv5JmB15yHpjYxVeOYdWWkoLMftr9-e_iS93Y_7m=t4Zw@mail.gmail.com> <20160309152505.GA28779@ubuntu-hedt> <CAJfpegv5KR_Hi-79a8oyb+R+tv9W3RYqy5pngUKSyauVNk2ScQ@mail.gmail.com> <20160309170726.GB28779@ubuntu-hedt> <CAJfpegvTuR-LZAVxeJAmojs=gcrM-t5dd-QyZM-bOYMYLRL6Dg@mail.gmail.com>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1364833

Show key headers only | View raw


On Mon, Mar 14, 2016 at 09:58:43PM +0100, Miklos Szeredi wrote:
> On Wed, Mar 9, 2016 at 6:07 PM, Seth Forshee <seth.forshee@canonical.com> wrote:
> > On Wed, Mar 09, 2016 at 04:51:42PM +0100, Miklos Szeredi wrote:
> >> On Wed, Mar 9, 2016 at 4:25 PM, Seth Forshee <seth.forshee@canonical.com> wrote:
> >> > On Wed, Mar 09, 2016 at 03:48:22PM +0100, Miklos Szeredi wrote:
> >>
> >> >> 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?
> >>
> >> Well, actually this is what the helper does:
> >>
> >>     sprintf(d, "fd=%i,rootmode=%o,user_id=%u,group_id=%u",
> >>         fd, rootmode, getuid(), getgid());
> >
> > Sorry, I was thinking of euid. So this may not be a problem.
> >
> >> So it just uses the current uid/gid.  Apparently no reason to do this
> >> in userland, we could just as well set these in the kernel.  Except
> >> for possible backward compatibility problems for things not using the
> >> helper.
> >>
> >> BUT if the mount is unprivileged or it's a userns mount, or anything
> >> previously not possible, then we are not constrained by the backward
> >> compatibility issues, and can go with the saner solution.
> >>
> >> Does that not make sense?
> >
> > But we generally do want backwards compatibility, and we want userspace
> > software to be able to expect the same behavior whether or not it's
> > running in a user namespaced container. Obviously we can't always have
> > things 100% identical, but we shouldn't break things unless we really
> > need to.
> >
> > However it may be that this isn't actually going to break assumptions of
> > existing software like I had feared. My preference is still to not
> > change any userspace-visible behaviors since we never know what software
> > might have made assumptions based on those behaviors. But if you're
> > confident that it won't break anything I'm willing to give it a try.
> 
> I'm quite confident it won't make a difference.

I was just about to go make these changes and discovered that the
user_id and group_id options are already mandatory, due to this check at
the bottom of parse_fuse_opt():

        if (!d->fd_present || !d->rootmode_present ||
            !d->user_id_present || !d->group_id_present)
                return 0;

So I'll simply drop those two lines which supply default values for
these options.

Thanks,
Seth

Back to linux.kernel | Previous | Next | Find similar | Unroll thread


Thread

Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside  of init_user_ns Seth Forshee <seth.forshee@canonical.com> - 2016-03-25 21:40 +0100

csiph-web