Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756131AbcCNU6s (ORCPT ); Mon, 14 Mar 2016 16:58:48 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:34935 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753137AbcCNU6o (ORCPT ); Mon, 14 Mar 2016 16:58:44 -0400 MIME-Version: 1.0 X-Originating-IP: [217.173.44.24] In-Reply-To: <20160309170726.GB28779@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> <20160309152505.GA28779@ubuntu-hedt> <20160309170726.GB28779@ubuntu-hedt> Date: Mon, 14 Mar 2016 21:58:43 +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: 2023 Lines: 45 On Wed, Mar 9, 2016 at 6:07 PM, Seth Forshee 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 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. Thanks, Miklos