Messages in this thread | | | Date | Wed, 18 Feb 2015 12:06:20 -0500 | From | "J. Bruce Fields" <> | Subject | Re: [RFC PATCH 5/8] KEYS: exec request-key within the requesting task's init namespace |
| |
On Fri, Feb 06, 2015 at 09:47:25AM +0800, Ian Kent wrote: > On Thu, 2015-02-05 at 15:14 +0000, David Howells wrote: > > > > > + /* If running within a container use the container namespace */ > > > + if (current->nsproxy->net_ns != &init_net) > > > > Is that a viable check? Is it possible to have a container that shares > > networking details? > > That's up for discussion. > > I thought about it and concluded that the check is probably not > sufficient for any of the cases. > > I left it like that because I'm not sure exactly what the use cases are, > hoping it promote discussion and here we are. > > I also think the current container environments don't share net > namespace with the root init net namspace, necessarily, because thy are > containers, ;) > > TBH I haven't looked at the user space container creation code but I > expect it could be done that way if it was needed, so the answer is yes > and no, ;) > > The questions then are do we need to check anything else, and what > environment should the callback use in the different cases, and what > other cases might break if we change it? > > For example, should the fs namespace also be checked for all of these > cases, since we're executing a callback, or is whatever that's set to in > the container always what's required for locating the executable.
What would be the disadvantage of setting UMH_USE_NS unconditionally here?
--b.
| |