From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Filesystem namespaces and uid/gid/lsm remapping Date: Sun, 22 Feb 2015 18:51:49 -0500 Message-ID: <20150222185149.73907103@synchrony.poochiereds.net> References: <31764.1417802507@warthog.procyon.org.uk> <87ppbtrefj.fsf@x220.int.ebiederm.org> <1424623968.2146.70.camel@HansenPartnership.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "Eric W. Biederman" , Lukasz Pawelczyk , Richard Weinberger , Andy Lutomirski , David Howells , Seth Forshee , Linux FS Devel , lsf-pc@lists.linux-foundation.org To: James Bottomley Return-path: Received: from mail-qg0-f43.google.com ([209.85.192.43]:59070 "EHLO mail-qg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752107AbbBVXvv (ORCPT ); Sun, 22 Feb 2015 18:51:51 -0500 Received: by mail-qg0-f43.google.com with SMTP id i50so22109708qgf.2 for ; Sun, 22 Feb 2015 15:51:51 -0800 (PST) In-Reply-To: <1424623968.2146.70.camel@HansenPartnership.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, 22 Feb 2015 08:52:48 -0800 James Bottomley wrote: > On Mon, 2014-12-08 at 15:59 -0600, Eric W. Biederman wrote: > > David Howells writes: > > > > > Andy Lutomirski wrote: > > > > > >> - How should LSM security labels be translated? > > > > > > I'm definitely interested in that. Especially with respect to how to deal > > > with SELinux + overlay{fs,}/unionmount. > > > > > > Also, I'm interested in how keyrings should interact with namespaces. Should > > > keys be namespaced? > > > > Key lookups are already per user namespace, so I would call that > > namespaced. We do have the question with keys, should we allow > > duplicate key values so that checkpoint/restart can carry keys between > > different kernels. > > > > > And I'm also interested in how upcalls, including to /sbin/request-key, should > > > be dealt with. > > > > Good question. There is some ongoing discussion on that right now. > > Aren't the upcalls exactly the same problem as NFS in a container (which > uses daemon upcalls). Can the existing solution for that be > generalised? > Not really, no... NFS (and nfsd) namespaceification (is that a word?) is designed around the network namespace. Start your daemons in a container and do your mount in the same container and everything "just works" due to the fact that the network namespace is the same. When you do something like a call_usermodehelper upcall, then things become more tricky. You have a network namespace, but nothing else, so you still have to know (for instance) what mount namespace to spawn the usermode helper in. Sorting that out is not at all straightforward and if we get it wrong it could be a giant security hole. Ian Kent is working on a patchset for this. The current idea is to ID the init process in the container where the mount occurred (or where nfsd was started) and use that to get an nsproxy to use for the UMH upcall. -- Jeff Layton