Received: by 10.223.148.5 with SMTP id 5csp6272550wrq; Wed, 17 Jan 2018 11:33:10 -0800 (PST) X-Google-Smtp-Source: ACJfBosRYuZqdlMTWhvP1JBb7+RPeiLsuiNGGfT8FdR4o8jR+3VF3CaDmmwXnZ/eWNzH4tQW1cN5 X-Received: by 10.84.133.163 with SMTP id f32mr12070048plf.48.1516217590103; Wed, 17 Jan 2018 11:33:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516217590; cv=none; d=google.com; s=arc-20160816; b=vpTK8i4C7VTZj0i2zPNF6tn1O/lHL+OmbaI8rLyimiH5B4pU8kizdjZizwEoT4oQ1E muM1vDYxpSvV6Hrui7yzv0A4qvoFCsqszjru+PIe32GZ+0WqsjWzTwrOOG5Y0AZWEDct 2gc6JAzw1KDtXnTshfRek0mhAjdci22OlzxQwUtYvB4wa3p30bFohRt6Wn9nulku1D1H XwHglXvlMGEggZULrgU+9q2UoKXn4nBRJyZ2j6cXU3n87y2SKT7inH9miEiibfd32d1c wc1HleJk9fCrWvQnM7/FBlUuZhtWeWZJ8+0ICWcU0M8ML6mkM7ThLNgkI5pAUZKAF688 G8Rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=FFdwrVMV1H2V5itAFOec/V0n91q7V4VgD6RceLSDplw=; b=mCFoPriEKFhWkBgLyT7lBW+OMg6SWPcC61eN7Uq94XR1JqlWsWtFM21QAOvPJG+xBA scl2ZIupoIkjiKAk2FiBJp1Bm+YDEUdvtfNIvbel60Vvx1uxM+dLZC6xefqxOZCkhhIC 5OwNq3UZIUpn4KbKwTA1zYOw8AjGpAu+hcl1gfejsTX5MTz2Gn4kg2zxOdTEXPuua/wo q/jurfBtOIOsAzx6lFKEXT5d1DMk4sOszuVcF62DBl0Vjc/VaNE8eTabz9tmOrEYvASv xvSliwIW33Y6nogEougBw22YKQkhY6sDz8NsaiRJeFyxfCxoXzB33OcO+BYUe6ERTw3p xvJA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v10si2353973ply.79.2018.01.17.11.32.56; Wed, 17 Jan 2018 11:33:10 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754542AbeAQTb5 (ORCPT + 99 others); Wed, 17 Jan 2018 14:31:57 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:39184 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753732AbeAQTby (ORCPT ); Wed, 17 Jan 2018 14:31:54 -0500 Received: from mail-io0-f200.google.com ([209.85.223.200]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ebtRB-0005s7-Ik for linux-kernel@vger.kernel.org; Wed, 17 Jan 2018 19:31:53 +0000 Received: by mail-io0-f200.google.com with SMTP id 199so2312301iou.0 for ; Wed, 17 Jan 2018 11:31:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=FFdwrVMV1H2V5itAFOec/V0n91q7V4VgD6RceLSDplw=; b=iK7Uf21dhEapzF+U9cCZqCCGu2sXkOrqrErfTaqEH1VbYf2mqbw/BXRWgMJq2u43fO Vf59z7HuBO0i4FTXhrZIEtLsS1VpvPCOQymHCsFeyEgALpTftzJz0Ldov8wmRzOJxrCG 8GeXkMbo/onDXvLNcYnE1BW9lEQwLbID8utL3d8hh2uMr3tQPFnT7ocwAMvI6m0MD8QF gycrTAVLAu9/K3stuLBqtn1Qsl93p4t5xMeJkm9ilOsuO3l7/8zY95XQ1BRMfJrPTt5l F8+Lh/jeVQf2BnSnNrBFobtV0fBM5CaoLLi/hBveyQcOcoLWtoHYTvPESWe9KIf0txlS WSbg== X-Gm-Message-State: AKwxytdQg8PWzZ/IxQjK8se3OPjamnaxlS9zwc5Ipgi0Z37EM9/xb5md WKRKGMkgaNiszDmQdaYiRTJP9aEfUByfiuJQHpnLom7qjeDofaLD5NYkNGY3XPmzCA4en9p9+nr gdMMmYq8ENfpmgdwjxfFPCWQF85j+yfMOwVldnP2AHg== X-Received: by 10.36.54.203 with SMTP id l194mr7943019itl.144.1516217512244; Wed, 17 Jan 2018 11:31:52 -0800 (PST) X-Received: by 10.36.54.203 with SMTP id l194mr7942999itl.144.1516217511937; Wed, 17 Jan 2018 11:31:51 -0800 (PST) Received: from localhost ([2605:a601:aae:1b20:7926:a98b:d63d:822e]) by smtp.gmail.com with ESMTPSA id a140sm2735298ioe.85.2018.01.17.11.31.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Jan 2018 11:31:39 -0800 (PST) Date: Wed, 17 Jan 2018 13:31:24 -0600 From: Seth Forshee To: Alban Crequy Cc: Dongsu Park , linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org, "Eric W . Biederman" , Miklos Szeredi , Sargun Dhillon , linux-fsdevel@vger.kernel.org, Tejun Heo , David Herrmann , Tom Gundersen Subject: Re: [PATCH 08/11] fuse: Support fuse filesystems outside of init_user_ns Message-ID: <20180117193124.GC3723@ubuntu-xps13> References: <20180117142935.GA3723@ubuntu-xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 17, 2018 at 07:56:59PM +0100, Alban Crequy wrote: > On Wed, Jan 17, 2018 at 3:29 PM, Seth Forshee > wrote: > > On Wed, Jan 17, 2018 at 11:59:06AM +0100, Alban Crequy wrote: > >> [Adding Tejun, David, Tom for question about cuse] > >> > >> On Fri, Dec 22, 2017 at 3:32 PM, Dongsu Park wrote: > >> > From: Seth Forshee > >> > > >> > In order to support mounts from namespaces other than > >> > init_user_ns, fuse must translate uids and gids to/from the > >> > userns of the process servicing requests on /dev/fuse. This > >> > patch does that, with a couple of restrictions on the namespace: > >> > > >> > - The userns for the fuse connection is fixed to the namespace > >> > from which /dev/fuse is opened. > >> > > >> > - The namespace must be the same as s_user_ns. > >> > > >> > These restrictions simplify the implementation by avoiding the > >> > need to pass around userns references and by allowing fuse to > >> > rely on the checks in inode_change_ok for ownership changes. > >> > Either restriction could be relaxed in the future if needed. > >> > > >> > For cuse the namespace used for the connection is also simply > >> > current_user_ns() at the time /dev/cuse is opened. > >> > >> Was a use case discussed for using cuse in a new unprivileged userns? > >> > >> I ran some tests yesterday with cusexmp [1] and I could add a new char > >> device as an unprivileged user with: > >> > >> $ unshare -U -r -m sh -c 'mount --bind /mnt/cuse /dev/cuse ; cusexmp > >> --maj=99 --min=30 --name=foo > >> > >> where /mnt/cuse is previously mknod'ed correctly and chmod'ed 777. > >> Then, I could see the new device: > >> > >> $ cat /proc/devices | grep foo > >> 99 foo > >> > >> On normal distros, we don't have a /mnt/cuse chmod'ed 777 but still it > >> seems dangerous if the dev node can be provided otherwise and if we > >> don't have a use case for it. > >> > >> Thoughts? > > > > I can't remember the specific reasons, but I had concluded that letting > > unprivileged users use cuse within a user namespace isn't safe. But > > having a cuse device node usable by regular users at all is equally > > unsafe I suspect, > > This makes sense. > > > so I don't think your example demonstrates any problem > > specific to user namespaces. There shouldn't be any way to use a user > > namespace to gain access permissions towards /dev/cuse, otherwise we > > have bigger problems than cuse to worry about. > > From my tests, the patch seem safe but I don't fully understand why that is. > > I am not trying to gain more permissions towards /dev/cuse but to > create another cuse char file from within the unprivileged userns. I > tested the scenario by patching the memfs userspace FUSE driver to > generate the char device whenever the file is named "cuse" (turning > the regular file into a char device with the cuse major/minor behind > the scene): > > $ unshare -U -r -m > # memfs /mnt/memfs & > # ls -l /mnt/memfs > # echo -n > /mnt/memfs/cuse > -bash: /mnt/memfs/cuse: Input/output error > # ls -l /mnt/memfs/cuse > crwxrwxrwx. 1 root root 10, 203 Jan 17 18:24 /mnt/memfs/cuse > # cat /mnt/memfs/cuse > cat: /mnt/memfs/cuse: Permission denied > > But then, I could not use that char device, even though it seems to > have the correct major/minor and permissions. The kernel FUSE code > seems to call init_special_inode() to handle character devices. I > don't understand why it seems to be safe. Because for new mounts in non-init user namespaces alloc_super() sets SB_I_NODEV flag in s_iflags, which disallows opening device nodes in that filesystem. Seth