On Sun, 22 Feb 2015 08:52:48 -0800
James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, 2014-12-08 at 15:59 -0600, Eric W. Biederman wrote:
> > David Howells <dhowells@xxxxxxxxxx> writes:
> >
> > > Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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 <jlayton@xxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
