Daniel Lezcano <dlezcano@xxxxxxxxxx> writes: > Eric W. Biederman wrote: >> Thinking it over a little more I have the following thought. >> >> For binding a socket to a namespace let's use the a fd arg. >> That way we can either supply another existing network socket >> or the result of an open call. Simple, and faster if you >> are creating more than one socket in the other network namespace. >> >> I really don't like the idea of binding a socket into a namespace. >> Especially after looking at the arguments to socket(2). >> The network namespace may be incomplete and you may create a socket >> in a network namespace that way that we could not exist normally. >> That plus it puts lots of races in code that finds the namespace of >> a socket. >> >> >> So in some form let's implement socketat. int socketat(int ns, int domain, int >> type, int protocol, int flags); > > Is the 'ns' arg a fd from a socket just after the unshare ? Yes. Any socket in the target namespace will do. >> We need the flags field so we can accomodate the O_CLOEXEC flag. >> >> >> That should be very straight forward. Implementable now, without >> a magic filesystem. And then the filesystem would just provide >> the global naming and process independence. > > Assuming the ns arg is a fd from a socket created in a specific network > namespace, I agree this is quite easy to implement and consistent with the > refcounting of the netns. Furthermore that follows the logic of the network > devices, one can be created in another netns using the pid as identifier. Yes. Your assumption is right. Using a fd as the descriptor we need to touch both socket creation and network device movement, but that should be sufficient. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers