On Thu, 23 May 2013 14:32:51 -0700 ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote: > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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 > Resurrecting this discussion after some time with some questions: If we went with option #2 above, would it be sufficient to simply pass a pid to the process? Then, since it runs as root, it could open /proc/<pid>/ns/mnt and pass that fd to setns()? Do you also have to chdir()/chroot() too? If so, how would one get the path for that? -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
