From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Filesystem namespaces and uid/gid/lsm remapping Date: Sun, 22 Feb 2015 09:01:50 -0800 Message-ID: <1424624510.2146.76.camel@HansenPartnership.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Linux FS Devel , lsf-pc@lists.linux-foundation.org, Seth Forshee , Lukasz Pawelczyk , "Eric W. Biederman" , Richard Weinberger To: Andy Lutomirski Return-path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:48936 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752120AbbBVRBw (ORCPT ); Sun, 22 Feb 2015 12:01:52 -0500 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, 2014-12-02 at 15:47 -0800, Andy Lutomirski wrote: > This should hopefully be a short topic, and it's possible that it'll > be settled by the time LSF/MM comes around, but: > > There's a fair amount of interest from different directions for > allowing filesystems with a backing store to be mounted (in the > mount-from-scratch sense, not the bind-mount sense) in a user > namespace. For example, Seth has patches to allow unprivileged FUSE > mounts. There are a few issues here, for example: > > - What happens to device nodes in those filesystems? You have to allow device nodes in mount namespaces. However, not all devices should be present, only the ones the owner of the namespace is allowed to either see (read only) or control (read/write). The specific problem for container security is allowing the user who can write to the device also to mount it ... because that lets them inject data known to cause a kernel crash and bring down the entire system or worse. The current solution is simply not to allow the owner both to write and mount, but this is becoming increasingly untenable using loopback images with containers for cascading overlays like docker does. James