Re: [PATCH 0/6] netns: add linux-vrf features via network namespaces

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> 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