Re: [RFC PATCH 5/8] KEYS: exec request-key within the requesting task's init namespace

[Ian Kent]

On Wed, 2015-02-18 at 15:59 -0500, J. Bruce Fields wrote:
> On Wed, Feb 18, 2015 at 12:31:32PM -0500, J. Bruce Fields wrote:
> > On Wed, Feb 18, 2015 at 12:06:20PM -0500, J. Bruce Fields wrote:
> > > 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?
> > 
> > In the nfs idmapping case, the mapping is per-nfs_client.
> > 
> > Can nfs_idmap_new be the one that calls umh_get_init_task, with the
> > corresponding put done in nfs_idmap_delete, or is there some reason that
> > doesn't work?
> 
> It's confusing sorting out possible use cases, but I think both of these
> are reasonable:
> 
> 	- mount an nfs filesystem from the host, then spawn containers
> 	  that all use that filesystem.
> 	- mount an nfs filesystem from within a container.
> 
> Your approach might work for the second, but in the first case we'll end
> up with idmappers from multiple containers all trying to do the
> idmapping for the shared filesystem.

These patches are examples for context.

Working out whether to run in a namespace or not was always going to be
difficult, specifically for the case you point out. Maybe we can make
use of some other information, namespace information in the super block
perhaps, or something else, or perhaps we will need to add some
information for this, not sure yet. We'll need to work together on that.

TBH, I'm not that focused on the use cases because the base
implementation is still undergoing significant change although I believe
the use of a flag to request namespace execution is a good approach.
That probably won't change.

Ian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/