[Devel] [RFC PATCH] fs: call_usermodehelper_root helper introduced

[Eric W. Biederman]

"J. Bruce Fields" <bfields at fieldses.org> writes:

> On Thu, May 23, 2013 at 03:55:47PM -0400, J. Bruce Fields wrote:
>> On Thu, May 23, 2013 at 09:05:26AM -0400, Jeff Layton wrote:
>> > What might help most here is to lay out a particular scenario for how
>> > you envision setting up knfsd in a container so we can ensure that it's
>> > addressed properly by whatever solution you settle on.
>
> BTW the problem I have here is that the only case I've personally had
> any interest in is using network and file namespaces to isolate nfsd's
> to make them safe to migrate across nodes of a cluster.
>
> So while the idea of making user namespaces and unprivileged knfsd and
> the rest work is really interesting and I'm happy to think about it, I'm
> not sure how feasible or useful it is.
>
> I'd therefore actually prefer just to take something like Stanislav's
> patch now and put off the problem of how to make it work correctly with
> user namespaces until we actually turn that on.  His patch fixes a real
> bug that we have now, while user-namespaced-nfsd still sounds a bit
> pie-in-the-sky to me.
>
>
> But maybe I don't understand why Eric thinks nfsd in usernamespaces is
> imminent.  Or maybe I'm missing some security problem that Stanislav's
> patch would introduce now without allowing nfsd to run in a user
> namespace.

The problem I saw is less pronounced but I think actually exists without
user namespaces as well.  In particular if we let root in the container
start knfsd in a network and mount namespace.  Then if that container
does not have certain capabilities like say CAP_MKNOD all of a sudden
we have a process running in the container with CAP_MKNOD.

I haven't had time to look at everything just yet but I don't think
solving this is particularly hard.

There are really two very simple solutions.
1) When we start knfsd in the container we create a kernel thread that
   is a child of the userspace process that started knfsd.  That kernel
   thread can then be used to launch user mode helpers.

   This uses the same code as is needed today to launch user mode
   helpers with just a different parent thread.

2) We pass enough information for the user mode helper to figure out
   what container this is all for.  File descriptors or whatever.
   Then the user mode helper outside the container using chdir and setns
   sets up the environment that the user mode helper typically expects
   and runs the process inside of the container.

Or we look at what the user mode helper is doing and realize we don't
need to run the user mode binary inside of the container.  If all it
does is query /etc/passwd for username to uid mapping for example (for
user namespaces we will probably care but not without them).

I don't think any of this is hard to implement.

I think user namespaces are imminent because after my last pass through
the code the remaining work looked pretty trivial, and as soon as the
dust settles I expect user namespaces become the common way to run code
in containers, which should greatly increase the demand for this feature
in user namespaces.

Eric