On Wed, 2014-12-10 at 18:21 -0500, Benjamin Coddington wrote: > On Wed, 10 Dec 2014, David Howells wrote: > > > Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx> wrote: > > > > > > This thread might be interesting: > > > > https://lkml.org/lkml/2014/11/24/885 > > > > > > > > > > Nice. I wasn't aware that Ian was working on this. I'll take a look. > > > > I'm not sure what the current state of this is. There was some discussion > > over how best to determine which container we need to run in - and it's > > complicated by the fact that the mounter may run in a different container to > > the program that triggered the mount due to mountpoint propagation. > > > > David > > The specific problem of how to run /sbin/request-key in the caller's > "container" for idmap and gssd (and other friends) became more generally a > problem of how to solve the namespace (or more generally again, "context") > problem for some users of kmod's call_usermodehelper. The nice thing about > call_usermodehelper is that you don't have to do a lot of work to set up a > process to get something done in userspace -- however it is sounding more > like we do need to work hard to set up context for some users. > > The userspace work needs to be done within a context that currently exists > or once existed, so the questions are where do we get that context and how > do we keep it around until we need it? > > I think there's agreement that the setup of that context should be basically > what's done in fork() for consistency and future work. So we get LSM and > cgroups, etc.. in addition to namespaces. And that's when the usermode helper init function is called, just before the exec, so I think that's the place it needs to be done. > > There are two suggested approaches: > > 1) Anytime we think we're going to later need to upcall with a context we > fork and keep a thread around to do that work. For NFS, that would look > like forking a thread for every mount at mount time. The user of this API > would be responsible for creating/maintaining the thread and passing it > along for work. Yeah, I don't think that's workable for large numbers of mounts and I don't think it's really necessary. > > 2) Specify that a usermodehelper should attempt to use a context rather than > the default root context. The context used would be taken from the "init" > process of the current pid_namespace. Either that init_process itself could > be asked to fork/execve or when the pid_namespace is created a separate > helper thread is reserved. I think this is doable using open()/setns() in a similar way to nsenter(1). We can worry about simplifying it once we have a viable approach to work from. The reality is that now user mode helpers are executed within the root context of init so I can't see why we can't use the context of init of the container for this. Modifying that along the way with a "struct cred" is probably a good idea although it isn't done now for user mode callbacks. The "struct cred" of the root init process surely isn't what needs to be used when executing in a container so something needs to be done. If we duplicate the same behaviour we have now for execution outside of a container then we'd use the "struct cred" of the container init process so maybe we do know where to get the cred, not sure about that though. > > I lean toward the second approach because I think it most closely matches > the context transistions that we have today, and can be more generally > applied. I'm pecking away at getting a rough implementation, which I plan > on asking Ian to review initially. I also have some patches so it's probably a good idea to share, ;) Ian -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
